rsync --daemon bypasses directory permissions on Linux (PR#3700)

[Martin Pool]

tshumway at ics.uci.edu wrote:

> On Linux, running 'rsync --daemon' as root bypasses some security
> restrictions, allowing access to otherwise inaccessible files.

Well, I can see why you think this is confusing, but I think rsync's
behaviour is reasonable and consistent with Unix's security design.

>  as 'nobody' I should not have been able to access *any* of the
> files below /home/fred

"should" here means "in my opinion", not "according to regular unix
security".  (I think it would be nice not to use emotive language like
"bypasses directory permissions" unless it's objectively true.)

Opening a file from the current directory on Unix does not imply
permission to traverse all the parent directories.  Opening ./foo only
requires +x on . and r on foo, whatever your current directory.

If you edit a configuration file as root to specifically allow access
to a directory then I think it's reasonable for the system to believe
you.

Leaving that aside: Permissions on directories above the chroot jail
are irrelevant by design.  If they were consulted on every operation
then the jail would be significantly less like a real root filesystem,
which would cause problems when for example mounting a root partition
from a recovery disk.  There are even good paranoid justifications for
wanting to set up a jail in a section of the system not accessible to
the users that work in the jail.

If you set permissions on a directory inside the jail they should work
in the normal way.

> Probably it needs to call seteuid() and chdir() beforehand to see if
> that will fail as the new user.  Unfortunately, seteuid() is
> non-POSIX and does not exist on some systems such as SVR4.  The only
> thing I can think of doing in that case is to fork a subprocess,
> have it do setuid() and chdir() and return success or failure, and
> check the exit code from the subprocess.  Yuck!

And even if you did that it is racy.

I guess you could argue that it would be more friendly for rsync to
behave differently, but at the moment it seems to me that would be
both hard to implement reliably and not necessarily easier to use or
understand.

You can also run rsync from inside something like rlinetd that will
chroot/setuid before launching the daemon, but I'm pretty sure all
those programs will have the same behaviour.

> Running an rsync service should be considered with the same security
> caveats as running an ftp service.

.. or any other service.

I'm open to being convinced that we should change it, but I'm not
convinced yet.

--
Martin