bug in permissions on symlinks

[Dave Dykstra]

On Mon, Dec 10, 2001 at 12:19:39PM +1100, Cameron Simpson wrote:
> On Fri, Dec 07, 2001 at 09:00:05AM -0600, Dave Dykstra <dwd at bell-labs.com> wrote:
> | 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()?
> 
> "nothing"!

You can't just use "nothing" because lchown() is also used by rsync to change
the ownership of regular files.  No distinction is currently made between
symlinks and other files.  That's what I was trying to say.


> | 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.
> 
> Right - this is what I would want. No lchown? Then down't test or change
> ownerships on symlinks. Likewise lchmod if these is such a beast.

Rsync is already skipping chmod on symlinks.


> | 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?
> 
> By reading the manual entries? Oh yeah, you're using configure :-(
> Ok, how in hell dows configure make such decisions now? Badly?
> 
> | I think this is a can of worms, and we don't even know if it's going to
> | affect anybody.
> 
> But we know that if it does affect somebody then the situation can be
> very bad indeed. And we also know that leaving symlinks the hell alone
> is pretty much harmless - they only need to point the right way - perms
> and ownerships are meaningless.
> 
> What you want is some testing which comes out with a SAFE_CHOWN macro, which
> is _undefined_ if there's no lchown equivalent.
> 
> Personally, for configure's purpose I'd be perfectly happy if
> "no lchown ==> no SAFE_CHOWN" because as remarked above, chowning
> symlinks is a waste of time.  Then as you trip across platforms with a
> chown-that-doesn't-follow-symlinks you can have configure these weirdos
> on a case be case basis. The current situation does not fail safe.
> The "do nothing without lchwon" approach at least is safe, and loses no
> _useful_ functionality.


Martin pointed out (at least I think it was Martin) that it does take away
the functionality of being able to remove symlinks from directories that
have the sticky bit on.  I don't think it's a good idea to remove
functionality from real systems in order to avoid a potential problem on a
hypothetical system.  However, in doing some testing I see that SunOS4
doesn't support the sticky bit (that is, mode 1000 on a directory to
prevent non-owners from removing files in the directory), and I see that
Solaris allows anybody to remove a symlink in a sticky directory.  So it
turns out that's only a problem on hypothetical systems too, and the only
thing it might do is look weird in an ls -l listing.  So I guess I don't
mind anymore if rsync would skip doing chown on symlinks on systems that
don't have lchown.

- Dave Dykstra