Bug 4263 - Change the daemon's symlink safety mode to allow absolute symlinks
Summary: Change the daemon's symlink safety mode to allow absolute symlinks
Status: CLOSED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.0
Hardware: Sparc Solaris
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-28 06:55 UTC by Bjorn Unden
Modified: 2008-07-26 10:05 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bjorn Unden 2006-11-28 06:55:44 UTC
I get problem with symbolic links when I do a backup between two servers using rsyncd on one of them.
When I get the backup everything works fine. See the GET-part belowe.
But when I shall put it back to the original place in the first server, rsync strips off the initial '/' in the symlink and this will not work. See the PUT-part belowe.
I have tryed it out a lot and it seems to work fine to 'GET' but not to 'PUT' when I use rsyncd.

GET
====
toos6<kalle> ls -al
total 6
drwxrwxr-x   2 root     other        512 Nov 27 19:15 .
drwxrwxr-x  11 root     other        512 Oct 25 14:40 ..
lrwxrwxrwx   1 root     other         47 Nov 27 19:15 LDAPBrowser -> /opt/ptc/Aphelion/SyntegraLDAPBrowser/ptclbe.sh

toos22<bin> rsync -av toos6::ptc/kalle/LDAPBrowser /backup/pdmlink_061126/Aphelion_latest/bin
receiving file list ... done
LDAPBrowser -> /opt/ptc/Aphelion/SyntegraLDAPBrowser/ptclbe.sh

sent 91 bytes  received 149 bytes  160.00 bytes/sec
total size is 47  speedup is 0.20
toos22<bin> ls -al
total 6
drwxrwxr-x   2 root     other        512 Nov 27 19:15 .
drwxrwxr-x  11 root     other        512 Oct 25 14:40 ..
lrwxrwxrwx   1 root     other         47 Nov 27 19:15 LDAPBrowser -> /opt/ptc/Aphelion/SyntegraLDAPBrowser/ptclbe.sh

PUT
====
toos22<bin> ls -al
total 6
drwxrwxr-x   2 root     other        512 Nov 27 19:15 .
drwxrwxr-x  11 root     other        512 Oct 25 14:40 ..
lrwxrwxrwx   1 root     other         47 Nov 26 23:00 LDAPBrowser -> /opt/ptc/Aphelion/SyntegraLDAPBrowser/ptclbe.sh

toos22<bin> rsync -av /backup/pdmlink_061126/Aphelion_latest/bin/LDAPBrowser toos6::ptc/kalle
building file list ... done
LDAPBrowser -> /opt/ptc/Aphelion/SyntegraLDAPBrowser/ptclbe.sh

sent 109 bytes  received 22 bytes  262.00 bytes/sec
total size is 49  speedup is 0.37

toos6<kalle> ls -al
total 6
drwxrwxr-x   2 root     other        512 Nov 27 19:15 .
drwxrwxr-x  11 root     other        512 Oct 25 14:40 ..
lrwxrwxrwx   1 root     other         47 Nov 27 19:15 LDAPBrowser -> opt/ptc/Aphelion/SyntegraLDAPBrowser/ptclbe.sh
Comment 1 Wayne Davison 2006-11-28 10:08:28 UTC
This is a safety feature when running the rsync daemon without chroot.  The easiest way to work around it is to set "use chroot = yes" in the config file.

I looked into improving the symlink safety mode to not modify an absolute symlink, but this will require changing rsync to chdir() into every destination directory when making changes (so that a user can't substitute a symlink for a directory in between a path's validity change and its use), so I deferred this change from 2.6.9 to a later release.  If 3.0.0 gets changed to use more chdir() calls, I will revisit making a non-chroot daemon have a safe symlink mode that doesn't mangle absolute symlinks.

Another, easier change would be to allow the config file to choose to accept unsafe symlinks in a non-chroot area.  You can manually disable the code that sanitizes the symlinks by looking for a sanitize_path() call inside an #ifdef SUPPORT_LINKS section in flist.c -- if that call were commented out, the symlinks would not be changed by a receiving daemon.
Comment 2 Matt McCutchen 2007-12-14 21:45:51 UTC
If you use the "munge symlinks" feature recently added to the development rsync, you won't be able to follow the symlinks on the daemon but the daemon will regurgitate them verbatim.
Comment 3 Wayne Davison 2007-12-15 11:42:14 UTC
As Matt points out, this is now possible.