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