bug in permissions on symlinks

tim.conway at philips.com tim.conway at philips.com
Sat Dec 8 02:25:02 EST 2001


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 at 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?"




More information about the rsync mailing list