<div dir="ltr"><div dir="ltr">On Sat, 12 Mar 2022 at 08:45, Florian Sager via rsync <<a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>Hi,</div>
    <div><br>
    </div>
    <div>I gave up using rrsync some years ago
      because of</div>
    <div>a) potential security issues with path
      references that can occur within the rsync execution in the call
      of rrsync<br>
    </div>
    <div>b) possibly unmatched rsync options
      (rrsync must be kept up-to-date to match new options _and_ some
      options need to be intentionally removed that may be required)</div>
    <div><br>
    </div>
    <div>So my solution on this is:<br>
      <br>
      - a login script (with suid bit in my case)<br>
      <br>
    </div>
    <div>- that creates/starts a docker image
      that limits path access and maps libs / rsync binary to be
      available in a limited environment, e.g. "alpine"<br>
    </div>
    <div><br>
    </div>
    <div>DOCKERRSYNC_BASE="/usr/bin/ionice -c 3
      $DOCKERBIN run -i --read-only --rm --security-opt
      no-new-privileges=true -v $RSYNC:/usr/bin/rsync:ro -v
      /lib/:/lib/:ro -v /lib64/:/lib64/:ro -v /usr/lib/:/usr/lib/:ro"</div>
    <div>$DOCKERRSYNC_BASE -v $SYNCDIR:$SYNCDIR
      -w $SYNCDIR $DOCKERIMAGE $SSH_ORIGINAL_COMMAND 2>/dev/null<br>
    </div>
    <div><br>
      If anybody sees security problems with this approach please tell
      us.<br></div></div></blockquote><div><br></div><div>I like the approach of using mounts to limit the paths that rsync can interact with, using docker like this or something else such as <a href="https://github.com/google/nsjail">https://github.com/google/nsjail</a> - but I might be a bit worried about allowing the user to run whatever commands they like, even inside such a tightly restricted container, if the client is at a much lower level of trust than the server.<br></div><div><br></div><div>There's no reason that this can't be combined with rrsync or any of the other methods described in this thread, for a "belt and braces" approach.</div><div><br></div><div>My personal favorite (which hasn't been mentioned yet) is to use rsync in daemon mode over ssh. You set the forced command in the authorized_keys line to something like "rsync --server --daemon --config /path/to/rsyncd.conf" and in that config file you define rsyncd modules to allow read/write or read-only access to various directories. You have to call it differently in the client though, for example with a "target" rsyncd module:<br></div><div><br></div><div>rsync -e ssh -a /foo "$server_hostname"::target/foo</div><div><br></div><div>... so I don't think this would work with the ansible rsync module without some hackery like adding a script to act as the local rsync client binary and having that script transform its arguments and call the real rsync.<br></div></div></div>