rsync - Jun 2018 - is "unintended library loading" actually possible?

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20180609/edea8946/attachment.html>

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.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			https://sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20180609/fe7cc699/signature.sig>