Bug 5457 - Add a client-side --munge-symlinks option
Summary: Add a client-side --munge-symlinks option
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: Other Linux
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-10 18:24 UTC by Matt McCutchen
Modified: 2008-07-28 20:06 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 Matt McCutchen 2008-05-10 18:24:56 UTC
Just as we have worked hard recently to secure daemons from untrusted clients, I think we should try to secure clients that pull data from untrusted daemons.  One of the easiest ways a daemon could compromise a client is to send a symlink to a sensitive area and a file under the symlink, e.g., "foo" -> "/home/matt" and "foo/.ssh/authorized_keys".  This is essentially the same exploit that necessitates symlink munging for not-purely-chroot daemon modules, just turned around.

I would like to be able to prevent this exploit while still storing some representation of the daemon's symlinks in the destination.  A natural way to support this would be to add a client-side option --munge-symlinks that munges received symlinks and unmunges sent symlinks just like the daemon parameter.  (Of course, the prefix "/rsyncd-munged/" isn't quite accurate for a client, but let's use it anyway for compatibility.)  --munge-symlinks would also make it possible to work around bug 4037 when the receiver is not a daemon.
Comment 1 Wayne Davison 2008-07-28 20:06:52 UTC
This is now present in git repository for 3.1.0 development.