bug in permissions on symlinks

[Dave Dykstra]

On Sat, Dec 08, 2001 at 12:05:44AM +1100, Martin Pool wrote:
> On  7 Dec 2001, Cameron Simpson <cs at zip.com.au> wrote:
> 
> > Please don't take this path - ownerships on symlinks are a pretty
> > meaningless concept
...
> > Why _not_ take the conservation approach "unless somebody reports a
> > problem" [sic]?
> 
> I'll speak to tridge, but I think we should pull this line out because
> of the scenario Cameron describes.


You can't just delete the #define, because the rsync code uses lchown()
throughout.  If you're on a system that doesn't have lchown(), what else
are you going to use other than chown()?

If you want to avoid a problem, the only thing you can do is to make sure
that rsync never attempts to change the ownership on a symlink when that
will cause a problem.  I just verified on Solaris that rsync is in fact
doing an lchown() on a symlink when the owner/group doesn't match.  If you
want to solve this problem correctly, it's also not enough to just do an
#ifndef HAVE_LCHOWN either, because as I found out, on some systems chown()
does the right thing.  You'd need a new configure test to find out whether
or not chown does the right thing on a symlink.  However, a lot of systems
allow only the super-user to do a chown, so how are you going to test it?

I think this is a can of worms, and we don't even know if it's going to
affect anybody.

- Dave