Chroot is not a secure function.  If not implemented very carefully it
can seriously undermine security rather than enhancing it.

If your concern is security maybe you shouldn't be using rsyncd at all.
Rsync over ssh works very well and has far superior authentication.  It
can also be restricted to a directory using the helper script rrsync
which comes with rsync (though some Linux distributions install it as
compressed documentation making it useless).

On 06/09/2018 09:52 AM, a.ikonnikov--- via rsync wrote:
> Please, help me understand if 'use chroot' option in daemon config is
> secure enough.
> Rsync manual has following lines:
>     As an additional safety feature, you can specify a dot-dir in the
>     module's
>     "path" to indicate the point where the chroot should occur.  This
>     allows rsync
>     to run in a chroot with a non-"/" path for the top of the transfer
>     hierarchy.
>     Doing this guards against unintended library loading (since those
>     absolute
>     paths will not be inside the transfer hierarchy unless you have used
>     an unwise
>     pathname), and lets you setup libraries for the chroot that are
>     outside of the
>     transfer.  For example, specifying "/var/rsync/./module1" will
>     chroot to the
>     "/var/rsync" directory and set the inside-chroot path to
>     "/module1".  If you
>     had omitted the dot-dir, the chroot would have used the whole path,
>     and the
>     inside-chroot path would have been "/".
> It *implies* that there could be a situation when rsync (in daemon mode)
> loads some libraries *after* doing chroot system call. But is this
> really possible?
> when stracing rsync daemon, I see no attempts to load libraries after
> calling chroot:
>     [pid 42312] geteuid()                   = 0
>     [pid 42312] chroot("/var/lib/mysql/")   = 0
>     [pid 42312] chdir("/")                  = 0
>     [pid 42312] setgid(0)                   = 0
>     [pid 42312] setgroups(1, [0])           = 0
>     [pid 42312] setuid(0)                   = 0
>     [pid 42312] setresuid(-1, 0, -1)        = 0
>     [pid 42312] geteuid()                   = 0

        Kevin Korb                      Phone:    (407) 252-6853
        Systems Administrator           Internet:
        FutureQuest, Inc.       (work)
        Orlando, Florida       (personal)
        Web page:             
        PGP public key available on web site.

Attachment: signature.asc
Description: OpenPGP digital signature

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