> hpa@transmeta.com (H. Peter Anvin) writes:
> > Incorrect. Neither the owner nor the mode of a symlink have any
> > effects, whatsoever.
>
> And that's too bad !
> Any idea why unix does it this way and why no unix derivative got rid of this
> appearently stupid behavior ?
>
Imagine two scenarios.
----- 1 -----> Symlink gives more priviledges than the file it points to
File secret.stuff has mode 0600 and is owned by root.
Symlink secret.link has mode 0644 and is owned by user6.
Just because user6 can read the symlink and manage to "see" that it points to
secret.stuff, the permissions on secret.stuff are such that user6 still can't
read it. So it doesn't matter what the symlink permissions are. Who cares. Unless
of course secret.stuff's inode pretends to have the same permissions as
secret.link's inode. But why?
----- 2 -----> Symlink gives fewer priveledges than the file it points to
File not-so-secret.stuff has mode 0666 and is owned by user6.
Symlink seemingly-secret.link has mode 0600 and is owned by root.
Now, how is the symlink providing any protection? So what it the access through
seemingly-secret.link prevents reading and writing for group and others? If you
really wanted to change the file you could just go directly to it.
Even if you wanted to put up with weird behavior like this (and I can't see how
you would) it still would make no sense. File permissions are stored in the
inode. The directory entry for a file points to an inode. Why should file access
be possible using a set of permissions from OUTSIDE the inode (from another
inode, i.e. the symlink)? It not only doesn't make sense, it's ugly.
If it were possible, any user could make a symlink to any file they know the name
for, set the permissions on it to allow them to write, and screw things up. If
you came up with a way to prevent this, then what would be the point of allowing
this kind of thing anyway?