The only circumstance where i could see symlink ownership being an issue
would be in the case where one might need to be changed, on those systems
which support that. Most i've seen delete and recreate the link, so if
the person needing to own the link has write, with no sticky bit, on the
containing directory,, he's good to go. Can anyone see another issue?
Certainly, the whole inane follow-link behaviour of chown and chmod are
big traps. I was shocked to see a chown down a users directory tree on
solaris make him the owner of many system files on the system i did it
from (nfs user dirs), and won't make the same mistake twice.
If rsync isn't going to have predictable behaviour on chowning (chmodding
too, on some systems), perhaps we should let it leave ownerships and modes
on symlinks at the system default.
Scenario:
I have an account on a system being backed up to another system, with
rsync.
I link /etc/security/password (or /etc/shadow/password, or /etc/shadow)
into my tree.
i get backed up.
I go to the other system.
I edit /etc/passwd, since it now belongs to me, moving my password into
root's password field ( saving the old one so i can cover my tracks).
I log in as root.
I do what I want.
I put the password back and fix the ownership.
I log back out of root.
If rsync gets a lchown or sensible chown, this won't happen, if it
doesn't, it could.
Tim Conway
tim.conway@philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
