Patch: disable path sanitization for modules rooted at "/"

Thor Simon Thor.Simon at twosigma.com
Tue Sep 20 12:03:32 UTC 2022


Indeed, we have “use chroot = false” – our application is a file distribution system where users authenticate as themselves and run rsync daemonized over ssh transport, rrsync-style.  We can’t run with “use chroot = true” as a workaround since the users are not root, and the chroot() system call failing is fatal for the rsync server process.

It’s our intention to let them access the entire host filesystem according to filesystem permissions alone.  And that worked fine until someone observed that his links from his home directory into ../../../../../etc were being sanitized.

I had a poke at the overall logic and ended up pondering the same fix it sounds like you’re settling on, but I wasn’t confident of my analysis so I went for the shortest patch that I was sure impacted only my use case.

Thor


From: Wayne Davison <wayne at opencoder.net>
Sent: Tuesday, September 20, 2022 1:11 AM
To: Thor Simon <Thor.Simon at twosigma.com>
Cc: rsync at lists.samba.org
Subject: Re: Patch: disable path sanitization for modules rooted at "/"

On Wed, Sep 7, 2022 at 6:25 AM Thor Simon wrote:
When running in daemon mode with a module rooted at “/” [...] it seems to me that path sanitization is not useful in this case.

In a typical Linux install, the default of "use chroot = true" already results in sanitize_paths = 0 for a path "/' module, so you must have "use chroot = false" set in your config file. The test you added is already a part of the prior "if" since module_dirlen is 0 when the module_dir is "/".

Thus, the weird part is why the code thinks that we need to force sanitation on for all use-chroot=off cases (especially when a chroot("/") doesn't accomplish anything extra for a "/" path).  In looking at the various module configuration possibilities, if we're not chrooted and not serving "/", then a check of just module_dirlen is sufficient to get sanitation enabled.  If we are chrooted and we have an inner module_dirlen, that also triggers the sanitization.  So it seems to me that the earlier check can be changed to be just "if (module_dirlen)".  I'll probably make that change after a bit more contemplation.

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20220920/b56d4aea/attachment.htm>


More information about the rsync mailing list