bug in permissions on symlinks

[Dave Dykstra]

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
> 
> So on Linux lchown changes the ownership on a symlink, whereas chown
> on a symlink will change the ownership of its target.  man lchown says
> 
>        In versions of Linux prior to 2.1.81  (and  distinct  from
>        2.1.46), chown did not follow symbolic links.  Since Linux
>        2.1.81, chown does follow symbolic links, and there  is  a
>        new  system  call  lchown  that  does  not follow symbolic
>        links.  Since Linux 2.1.86, this new call  (that  has  the
>        same  semantics as the old chown) has got the same syscall
>        number, and chown got the newly introduced number.
> 
> 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.  
> 
> 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.  (To be really tricky I guess we could
> seteuid() before creating the link.)
> 
> David, do you have a machine that behaves like this?


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.

- Dave Dykstra