bug in permissions on symlinks
dwd at bell-labs.com
Fri Dec 7 02:06:10 EST 2001
On Fri, Dec 07, 2001 at 12:58:31AM +1100, Cameron Simpson wrote:
> Not so. The sunos4 boxen don't have lchown()
You're right. However, the chown man page says it doesn't follow symlinks:
If the final component of path is a symbolic link, the own-
ership and group of the symbolic link is changed, not the
ownership and group of the file or directory to which it
> and I'd expect the orignal
> BSD stuff where symlinks came in didn't have it. (I certainly had never
> tripped over it).
I don't have any other BSD systems, but I would think they'd be like
> Another counter example - Apollo symlinks were special directory entries,
> not objects with inodes, and chowning them was meaningless. SInce the
> target permissions were always enough anyway (permissions on a symlinks
> can be trivially bypassed by opening the full path, and symlinks are
> not writable themself - only creatable), so inodeless implementations
> are both feasible and sensible.
Does anybody run rsync on Apollo?
> Please - if there's no lchown DO NOT chown symlinks. It is silently
I say let's don't bother to change it unless somebody reports a problem.
> It has long offended me that the default chown/chgrp/chmod calls follow links
> - to my mind the _only_ system calls that should follow links are open() and
> chdir(). It would have made for a much saner and safer world.
Looks like the BSD inventors of symlinks agreed with you for chown & chgrp
(but not chmod). Only SystemV messed up when they added symlinks, and as
a result had to come up with lchown.
- Dave Dykstra
More information about the rsync