The GPFS attribute patch and sandboxing rsync when running in --server mode
chris.o.cowan at gmail.com
Sun Apr 25 16:53:32 UTC 2021
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rsync