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.


From: Wayne Davison <>
Sent: Tuesday, September 20, 2022 1:11 AM
To: Thor Simon <>
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 

Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options:
Before posting, read:

Reply via email to