Messages in this thread |  | | Date | Tue, 9 Jul 1996 09:03:40 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: How does chown(2) works with symlinks? |
| |
On Tue, 9 Jul 1996, Jeremy Fitzhardinge wrote: > > So long as you can open the file. Its possible you want to chown a file you own > but can't open, and if chmod is consistent with chown (which I certainly hope > is the case), you won't be able to chmod it before trying to open it.
Note that only root can chown() files under Linux (or any other reasonable system - you end up with messes that only root can fix up if you allow normal users to chown() their files, not to mention quotas), so this is not a problem.
Chmod _would_ be a problem, but as symbolic links can't have permissions (a mistake in my opinion, but hey, that's how it is) the decision there is trivial (always follow the link for chmod()).
> > If you use "chown()" on the > > pathname it will change the synlink itself (if you think about it, that is > > actually the reasonable behaviour: otherwise you could never change the owner > > of the symlink). > > It might be reasonable behaviour if there were ever a need to change the owner > of a symlink. However, seeing as a symlink is a mere loophole in the namespace > and has no function in itself, the owner, like its mode, is completely irrelevent.
You're wrong: it's entirely reasonable to chown() a symlink, one reason being that root may create a new user, then build a default set of system files for the user in his home directory, and then do a
chown -R newuser ~newuser
Or something to that effect (actually, the more "normal" thing might be just a UID re-organization where you want to change the UID of a existing user for some reason).
You don't want to leave the symlink as the old UID, because there are actually a few special rules about UID's (sticky bits on world-writable directories, for example).
Linus
|  |