bug in permissions on symlinks

[Cameron Simpson]

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"!

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

| 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.
-- 
Cameron Simpson, DoD#743        cs at zip.com.au    http://www.zip.com.au/~cs/

The fortunate man knows how much he can safely leave to chance.
	- Lady Barbara Hornblower