rsync - May 2021 - The GPFS attribute patch and sandboxing rsync when running in --server mode

First my apologies if this ended up getting double posted!

I'm looking at the GPFS attribute patches that Ronnie Sahlberg originally
created.  The last reference I've seen on this list was using rsync
v3.0.9.   (Orlando Richards mentions looking at it, and I know there is
also a patch on github, in the gpfsug/gpfstools repo.)

We had a working version of this 3.0.9 hack for years, but I'm trying to
forward port this to v3.2.3.  I'm wondering:

   - Has anyone else forward ported this to a version > 3.0.9.
   - Any caveats I need to be aware of?
   - Still trying to get my head around the attribute cache, and the
   various refactorings that occurred between 3.0.3 and 3.0.9.   The GPFS hack
   seems to have two separate options --gpfs-attrs and --gpfs-attrs-cache.  (I
   know Ronnie, so hopefully I'll be able to get in touch with him, and
he'll
   remember more specifics.)

 I?ve also been looking at several solutions that try to sandbox
openssh/rsync.    These include rssh (which should not be used anymore,
because it's Abandon-ware.  But, it is what I am most familiar with), GNU
rush, and daethnir/authprogs on github.    None of these seems to be able
to provide me the control, with rsync, when  ?protect-args is used.  Unless
I?m mistaken, the filtering has to be done by the rsync --server --sender
process itself, since it's the only thing that has visibility to the
filepath passed in the ssh channel.

This got me thinking, has anyone ever considered a ?plug-in? / ?shim?
interface for rsync, to allow an admin to insert some extra security
control on the src filepath?   If not a plugin, perhaps a special command
line flag to rsync, to identify an "exit".  Perhaps something like
openssh's Local Command option?

I realize that if done incorrectly, it could cause more problems than it
fixed.

-- 
Chris Cowan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20210425/63820282/attachment.htm>

On Sun, 25 Apr 2021 at 17:53, Chris Cowan via rsync
<rsync at lists.samba.org> wrote:
>
>  I?ve also been looking at several solutions that try to sandbox
openssh/rsync.    These include rssh (which should not be used anymore,  because
it's Abandon-ware.  But, it is what I am most familiar with), GNU rush, and
daethnir/authprogs on github.    None of these seems to be able to provide me
the control, with rsync, when  ?protect-args is used.  Unless I?m mistaken, the
filtering has to be done by the rsync --server --sender process itself, since
it's the only thing that has visibility to the filepath passed in the ssh
channel.
I like to use rsync in daemon mode over ssh for that type of thing, because:

* you don't need a shim, just make the ssh forced command "rsync
--server --daemon --config /path/to/some/rsyncd.conf ."
* the --daemon turns on extra server side security checks
* you always have --protect-args when in daemon mode
* you can sandbox the transfer root and other things with settings in
the rsyncd.conf

Example rsync.conf for allowing reading of /var/lib/{foo,bar} but
writes to only /var/lib/foo :


use chroot = no

[foo]
path = /var/lib/foo
read only = no

[bar]
path = /var/lib/bar
read only = yes


On the client side you use the :: syntax to specify a module in an
rsync daemon along with "-e ssh" to get daemon mode over ssh, for
example to write to /var/lib/foo/someplace you could:

 rsync -e ssh [OTHER OPTIONS] /tmp/new-foo-things ${hostname}::foo/someplace

So, I'm wondering if you or anyone else knows a way to force rsync into
--daemon mode from the server side?
Unless I'm wrong, I probably still need one of the shims I mentioned.

Perhaps I could do the poor man's by writing a wrapper script (or even
executable) to basically add the re-exec the command and adding the --daemon
option.

Unless there's some way to do this via sshd_config that I am unaware of?


On 4/25/21, 1:38 PM, "Nick Cleaton" <nick at cleaton.net> wrote:
>    On Sun, 25 Apr 2021 at 17:53, Chris Cowan via rsync
>    <rsync at lists.samba.org> wrote:
>    >
>    >  I've also been looking at several solutions that try to
sandbox openssh/rsync.    These include rssh (which should not be used anymore, 
because it's Abandon-ware.  But, it is what I am most familiar with), GNU
rush, >    >  and daethnir/authprogs on github.    None of these seems to
be able to provide me the control, with rsync, when protect-args is used. 
Unless I'm mistaken, the filtering has to be done by the rsync --server
--sender >   > process itself, since it's the only thing that has
visibility to the filepath passed in the ssh channel.
>
>    I like to use rsync in daemon mode over ssh for that type of thing,
because:
>
>    * you don't need a shim, just make the ssh forced command
"rsync
>    --server --daemon --config /path/to/some/rsyncd.conf ."
>    * the --daemon turns on extra server side security checks
>    * you always have --protect-args when in daemon mode
>    * you can sandbox the transfer root and other things with settings in
>    the rsyncd.conf
>
>    Example rsync.conf for allowing reading of /var/lib/{foo,bar} but
>    writes to only /var/lib/foo :
>
>
>    use chroot = no
>
>    [foo]
>    path = /var/lib/foo
>    read only = no
>
>    [bar]
>    path = /var/lib/bar
>    read only = yes
>
>
>    On the client side you use the :: syntax to specify a module in an
>    rsync daemon along with "-e ssh" to get daemon mode over ssh,
for
>    example to write to /var/lib/foo/someplace you could:
>
>    rsync -e ssh [OTHER OPTIONS] /tmp/new-foo-things
${hostname}::foo/someplace