rsync - Apr 2018 - [Bug 13364] New: rsyncd clips trims relative symlinks outside of source tree

https://bugzilla.samba.org/show_bug.cgi?id=13364

            Bug ID: 13364
           Summary: rsyncd clips trims relative symlinks outside of source
                    tree
           Product: rsync
           Version: 3.1.3
          Hardware: x64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: samba.severach at spamgourmet.com
        QA Contact: rsync-qa at samba.org

Created attachment 14099
  --> https://bugzilla.samba.org/attachment.cgi?id=14099&action=edit
setup instructions and copier

A relative symlink that points outside the source tree is copied properly when
copying server -> client. When copying client -> server leading
'../' are
trimmed until it fits in the source tree.

I need symlinks outside the source tree to not be trimmed copying in either
direction.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13364

--- Comment #1 from Dave Gordon <dg32768 at zoho.eu> ---
Comment on attachment 14099
  --> https://bugzilla.samba.org/attachment.cgi?id=14099
setup instructions and copier

This is a documented feature; see rsyncd.conf(5):

  munge_symlinks
    ...
    When this parameter is disabled on a writable module and "use
chroot" is
    off (or the inside-chroot path is not "/"), incoming symlinks will
be
    modified to drop a leading slash and to remove ".." path elements
that
    rsync believes will allow a symlink to escape the module’s hierarchy.
    There are tricky ways to work around this, though, so you had better
    trust your users if you choose this combination of parameters.

Unless you want the symlinks to be usable on the server as well as the client,
why not enable munge-symlinks. That way the client will get back the same
out-of-tree symlink as it started with, even though it will have had a
different content while on the server.

.Dave.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13364

--- Comment #2 from Dave Gordon <dg32768 at zoho.eu> ---
Comment on attachment 14099
  --> https://bugzilla.samba.org/attachment.cgi?id=14099
setup instructions and copier

Having set up an rsync daemon (on localhost:10873):

$ # Initial fetch of daemon's directory:
$ rsync -ii -av rsync://localhost:10873/testrsync/ testrsync/
receiving incremental file list
.d..t...... ./
cL+++++++++ foo -> ../foo
sent 30 bytes  received 91 bytes  242.00 bytes/sec
total size is 6  speedup is 0.05
$ ls -lRa rsyncd/testrsync/ testrsync/
rsyncd/testrsync/:
total 4
drwxr-xr-x 1 dg32768 users  6 Apr  4 16:25 ./
drwxr-xr-x 1 dg32768 users 80 Apr  4 16:59 ../
lrwxrwxrwx 1 dg32768 users  6 Apr  4 16:15 foo -> ../foo

testrsync/:
total 4
drwxr-xr-x 1 dg32768 users    6 Apr  4 16:25 ./
drwxr-xr-x 1 dg32768 users 1846 Apr  4 16:58 ../
lrwxrwxrwx 1 dg32768 users    6 Apr  4 16:15 foo -> ../foo

$ # Refetch the same data:
$ strace -e trace=symlink rsync -ii -av rsync://localhost:10873/testrsync/
testrsync/
receiving incremental file list
.d          ./
.L          foo -> ../foo
sent 30 bytes  received 91 bytes  242.00 bytes/sec
total size is 6  speedup is 0.05
$ # Here the rsync itemisation shows that it *examined* the symlink but
$ # did *not* recreate it -- note that strace shows no symlink(2) calls.
$ # So no bug here either :)

.Dave.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13364

--- Comment #3 from Chris Severance <samba.severach at spamgourmet.com>
---
>enable munge-symlinks. That way the client will get back the same
out-of-tree symlink as it started with
This is a lousy option for backups. The only way to get my original links back
is to pull the restore through rsync. Restoring directly from the rsyncd server
will copy the munged links.
>Unless you want the symlinks to be usable on the server
This is exactly what is required. It's not a server at all. It's two
clients
both of which must have the same usable tree, one of which runs rsyncd to
accept updates from the other.

I tried enabling chroot and the leading path was still clipped
client->server.
>There are tricky ways to work around this
This is what I'm looking for. There should be no security for --links since
copying links can never reach outside the server tree. --copy-links and
--copy-unsafe-links could reach outside the tree so need to be limited whether
or not the unsafe link was from the client.

I can build the links on both clients so --safe-links could work but I need a
way to silence the warnings out of the -v listing.

Shortening the rsyncd "path=" so that the links become inside the tree
could
work but rsync has no usable way to specify only one directory without causing
the links to be considered outside outside the tree.

cd baz2; rsync ./ rsync://.../baz1/ # original case

rsync bar2/ rsync://.../root/bar1/ # shortened path
Links going to bar1 accessible by /root/ are considered outside of the bar1
tree and clipped.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

On 04/04/18 20:52, just subscribed for rsync-qa from bugzilla via rsync
wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=13364
> 
> --- Comment #3 from Chris Severance <samba.severach at
spamgourmet.com> ---
>> enable munge-symlinks. That way the client will get back the same
out-of-tree symlink as it started with
> 
> This is a lousy option for backups. The only way to get my original links
back
> is to pull the restore through rsync. Restoring directly from the rsyncd
server
> will copy the munged links.
It's a very sensible option for *backups* i.e. where one host holds a
*backup* copy of the contents of another host's filesystem, but does not
itself use or interpret those contents.

Another useful option for a genuine backup server is --fake-super, so
the user-ids and permissions on the two systems don't have to be
correlated, and a non-root backup daemon can back up files that are
owned by any user. But again, you have to use rsync to reverse the effect.
>> Unless you want the symlinks to be usable on the server
> 
> This is exactly what is required. It's not a server at all. It's
two clients
> both of which must have the same usable tree, one of which runs rsyncd to
> accept updates from the other.
So the problem is that you're trying to implement a symmetric p2p
operation using an explicitly asymmetric client-daemon (server) mode.
If you use the non-daemon mode you can initiate the operation from
either peer, and there are no limitations on the targets of symlinks
(with the right choice of options).

Why do you think it's necessary to use the daemon mode?
> I tried enabling chroot and the leading path was still clipped
client->server.
> 
>> There are tricky ways to work around this
> 
> This is what I'm looking for. There should be no security for --links
since
> copying links can never reach outside the server tree. --copy-links and
> --copy-unsafe-links could reach outside the tree so need to be limited
whether
> or not the unsafe link was from the client.
Huh? If you allow a client to upload an unmunged symlink to (say)
/etc/passwd into a r/w directory on the server, and then download it
with the --copy-links option, the client gets a copy of the server's
real /etc/passwd, even though that file doesn't lie under the pathparameter
in the daemon config file. That's a fairly big security hole
if one's not *very* careful about setting appropriately limited uid/gid
mappings in the config -- and if you do that, then you can't back up
files with arbitrary ownership.
> I can build the links on both clients so --safe-links could work but I need
a
> way to silence the warnings out of the -v listing.
> 
> Shortening the rsyncd "path=" so that the links become inside the
tree could
> work but rsync has no usable way to specify only one directory without
causing
> the links to be considered outside outside the tree.
> 
> cd baz2; rsync ./ rsync://.../baz1/ # original case
> 
> rsync bar2/ rsync://.../root/bar1/ # shortened path> 
> Links going to bar1 accessible by /root/ are considered outside of the bar1
> tree and clipped.
Create a dummy bar1/ on the client and include it in the files being
uploaded?

.D.

https://bugzilla.samba.org/show_bug.cgi?id=13364

Wayne Davison <wayne at opencoder.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #4 from Wayne Davison <wayne at opencoder.net> ---
As long as "munge symlinks = false" is set for your module (which is
the
default with "use chroot = true" and a normal path value is set), then
rsync
doesn't tweak the symlinks in the transfer at all.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.