bug in permissions on symlinks

[Dave Dykstra]

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


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


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

I say let's don't bother to change it unless somebody reports a problem.


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

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