rsync - Sep 2022 - Patch: disable path sanitization for modules rooted at "/"

When running in daemon mode with a module rooted at "/", it is not
possible to "escape" the module.

Not by prefixing a link target with "../../../../../../..".
Not by prefixing a link target with "/" nor "////".

So it seems to me that path sanitization is not useful in this case.  And it
breaks stuff.  In particular, I have a file distribution system where large
numbers of authenticated users can use rsync in daemon mode as a forced SSH
command, authenticating as themselves, and path sanitization damages links like
"../../../../../../../etc/localtime" in user directories - which may
be dubious in purpose, but which are harmless.  And I am not the arbiter of my
users' data in this sense.  Turning on symlink munging of course damages
these data even more - I would prefer to not have it damaged at all.

Trivial fix attached.

Thor

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20220907/8560eaa7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clientserver.diff
Type: application/octet-stream
Size: 687 bytes
Desc: clientserver.diff
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20220907/8560eaa7/clientserver.obj>

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/20220919/7176b48e/attachment.htm>