Re: Proposal: restrict link(2)

nw (
Fri, 13 Dec 1996 18:18:36 +0000 (GMT)

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

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

> 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.

> 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.

> 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
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.

nathan wagner