bug in permissions on symlinks

[Martin Pool]

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?

--
Martin