> Date: Fri, 13 Dec 1996 18:18:36 +0000 (GMT)
> From: nw <nw@hydaspes.if.org>
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: Proposal: restrict link(2)
>
>
> Dan Merillat wrote:
>
> > On Fri, 13 Dec 1996, Steve VanDevender wrote:
> >
> > > "And therefore modify?" I get the impression that some of the people
> > > who are arguing about this don't at all understand the semantics of
> > > link().
> > >
> > > If you link /etc/shadow to /tmp/shadow, you have done none of the
> > > following:
> > >
> > > * changed the permissions of /tmp/shadow
> > > * changed the owner or group owner of /tmp/shadow
> > >
> > > Not only have you not changed those, you cannot change those. You have
> > > created another reference to the inode, and that's all.
> >
> >
> > Theodore Y. Ts' <tytso@MIT.EDU> Writes:
> >
> > > Incorrect. Being able to link to a file does not mean you can change
> > > it.
> >
> I think that the various participants are each using the word "modify", and
> possibly word "file" to mean slightly different things. You make some
> interesting points but perhaps a bit more precision of speech would help the
> discussion.
file: an abstraction that is the union of all the information about a piece
of data. This includes the data itself, a name, a location, and
permissions.
modify: to change _ANY_ of the above.
>
> If i may respond to some of your specific statements...
>
> > Sheesh. I said link() modifies a file. And it _DOES_ It changes the file
> > location,
>
> What do you mean by "file location"? It adds a new pointer to the inode in
> the directory tree; it does not move the previous pointer, nor any of the data
> blocks.
Yes... that means it is accessable from a new location... and it does not
notify the original owner that this is the case. Normally, not a problem.
However, if I delete a file I expect it to be deleted... I don't expect
some random user to have linked it to his directory. This is espically
common in university environments with low disk quotas.
>
> > which _MAY_ change permissions of that file! (think of a
> > group-only
> > directory and someone in that group makes a link outside of it)
>
> The new pointer may not be accessible to the same set of user/group ids as the
> old one, but i don't see how this changes the permissions of the file.
Um, I believe you know more about unix permissions then that.
harik@chaos:~$ ls -alt ~/hidden
total 12
drwx------ 2 harik admin 1024 Dec 13 14:51 .
-rwxrwxrwx 1 harik admin 1240 Dec 13 14:51 mycreditcards
drwxr-xr-t 47 harik admin 9216 Dec 13 14:50 ..
Would you say that the file is worldreadable? worldwritable? No, because
the permissions on the file are the SUM of the permissons of the file and
the directory...
So a hard link outside of this directory WOULD change the permissions...
not on the inode, but it changes the ability to access the file.
Granted, nobody would be stupid enough to make their credit card numbers
world writable, but the example holds. hard links can change the ability
to access a file WITHOUT the owner's permission or knowledge.
For a more applicable example:
/usr/sbin/admin is a directory that only people in group admin can access.
inside are user modification tools, suid root, executable by group user-adm.
Therefore, the permission to modify a user is dependant on being in both
group admin and user-adm. Why two levels? Because on any heirarchy there
are going to be groups of administration that overlap.
Makes sense right? Except having any directory on the
same partition as /usr/sbin/admin writable by group admin destroys the
entire scheme. And that's not something that many people realise.
So, simply put, link() bypasses ALL group restrictions except the one on
the file itself... and therefore it is something that administrators
should be able to restrict.
> > It changes the lifespan of the file.
> > It takes control of the file away from the owner, who can no longer delete
> > the file.
> > link() in a directory you own, mode 700. Now the owner _CANNOT_
> > touch the file after they remove it!
>
> Interesting point. However if the mere existence of the data blocks, even
> if they are unreadable to anyone else, disturbs you that much, you should
> encrypt the data, and/or don't keep it on a multi-user system.
I'm not talking about hiding data. I'm saying that the lifespan of
a file is something that only the owner should be able to modify.
Obviously you want to write /dev/zero or /dev/random all over your
data if you want to make sure it's deleted... and burn all tape backups,
etc. But I'm talking about transitory files that get their lifespan
prolonged by another user. Besides, if you want to delete a file, do you
_REALLY_ want to have to
stat filename
ls -i filename
find /<mountpoint> -inum <number> -exec rm {}
>
> > So yes, link() DOES modify a file
> > and nobody can claim it does not!
>
> I think you mean "should", not "can". But, as noted above, i think you are
> using the word "file" to mean something different than some others in this
> discussion. You seem to think of the file as some sort of platonic ideal
I like that quote... "platonic ideal entity" If you want to propose a
different term for the whole thing, go ahead. So yes, I'm talking
about the whole file entity, because a file is just that: the sum
of the data blocks, the inode and the directory entery.
> entity, while others are using the word to mean just the data blocks of the
> file, while yet others seem to mean the data blocks + inode.
True. But then they should be talking about datablocks or the inode or both.
--Dan