bug in permissions on symlinks
cs at zip.com.au
Fri Dec 7 00:58:31 EST 2001
On Mon, Dec 03, 2001 at 12:42:19PM -0600, Dave Dykstra <dwd at bell-labs.com> wrote:
| On Sun, Dec 02, 2001 at 11:52:08PM +1100, Martin Pool wrote:
| > I see rsync has this in rsync.h
| > #ifndef HAVE_LCHOWN
| > #define lchown chown
| > #endif
| > I'm not at all sure the way we're calling it is correct. There could
| > be systems where there is no lchown, but chown on a symlink still
| > follows the link. I seem to remember Solaris behaving this way, but
| > I'm not sure if that is the system call or just the chown command.
The command definitely follows the link.
| > In this case we might be accidentally setting the ownership of the
| > destination. On such a machine we should just not set the ownership
| > of the symlink at all.
Definitely. Chown following symlinks is one reason I NEVER use the "chmod
-R" and "chown -R" commands, instead playing annoying games with "find
! -type l -print | xargs ...".
| No, I don't. Even my oldest systems have symbolic links and also have
| lchown. I think any system that has symbolic links would have to
| implement the lchown/chown distinction, so I don't think it's something
| to worry about.
Not so. The sunos4 boxen don't have lchown(), and I'd expect the orignal
BSD stuff where symlinks came in didn't have it. (I certainly had never
tripped over it).
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.
Please - if there's no lchown DO NOT chown symlinks. It is silently
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.
Cameron Simpson, DoD#743 cs at zip.com.au http://www.zip.com.au/~cs/
You've failed to miss my point entirely, though you've succeeded mostly.
- Mark Vieselmeyer
More information about the rsync