Bug 5275 - user id mapping stopped working with 3.0.0pre10
user id mapping stopped working with 3.0.0pre10
Status: CLOSED INVALID
Product: rsync
Classification: Unclassified
Component: core
3.0.0
x86 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-21 16:01 UTC by Brian K. White
Modified: 2008-07-26 10:31 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian K. White 2008-02-21 16:01:29 UTC
I'm running the daemon natively (no ssh/rsh) on several suse linux boxes of various versions and cpu types (and freebsd and sco open server) and all use a config file that runs rsyncd as root and all boxes talk to each other. rsync versions range from 2.6.6 to 3.0.0pre9 and up to 3.0.0pre9 everything has been fine.

3.0.0pre10, when acting as the server, fails to do user id mapping.

Any version client (2.6.9, 3.0.0pre1, 3.0.0pre9, 3.0.0pre10), sending to, or receiving from, a 3.0.0pre10 server, transferring files ownded by a user that exists on both boxes but with different uid's, the files do not get the user id  translated on the receiver.

Any version client (including 3.0.0pre10), sending to, or receiving from, a 3.0.0pre9 or lower server, works.

That is, the error is dependant on the property of 3.0.0pre10 being in daemon mode. Doesn't matter what version the client is, and doesn't matter which side is the sender or the receiver of a file. All that matters is, if the server is 3.0.0pre10, then uid mapping doesn't happen.
Comment 1 Matt McCutchen 2008-02-21 18:28:03 UTC
This is the expected behavior, however unfortunate.  Beginning with rsync 3.0.0pre10, the default is for a daemon never to map uids/gids by name in modules with "use chroot" enabled.  This closes a vulnerability where a client might be able to compromise a daemon process by uploading shared libraries that the daemon process would load in an attempt to do uid/gid mapping.  If your modules are read-only or you have taken other security measures, you can set "numeric ids = true" in the configuration to re-enable uid/gid mapping.  See section `3. Daemon advisory for "use chroot = yes"' of http://rsync.samba.org/security.html for more information.
Comment 2 Matt McCutchen 2008-02-21 18:28:49 UTC
Whoops, I meant "numeric ids = false".  That one is easy to get backwards.
Comment 3 Brian K. White 2008-02-21 21:35:15 UTC
OK, but, here is rsyncd.conf, and the command line was just "--daemon"
========================================================
uid = root
gid = sys
read only = false
#use chroot = true
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
#hosts allow = trusted.hosts
secrets file = /etc/rsyncd.secrets

[root]
        path = /
        auth users = root
================================================

Is use chroot enabled by default so that commenting it out is not enough to disable it?

In any event, numeric ids = false works so thanks
Thats a good catch, I'll have to think about that one...

Comment 4 Brian K. White 2008-02-21 21:35:39 UTC
OK, but, here is rsyncd.conf, and the command line was just "--daemon"
========================================================
uid = root
gid = sys
read only = false
#use chroot = true
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
#hosts allow = trusted.hosts
secrets file = /etc/rsyncd.secrets

[root]
        path = /
        auth users = root
================================================

Is use chroot enabled by default so that commenting it out is not enough to disable it?

In any event, numeric ids = false works so thanks
Thats a good catch, I'll have to think about that one...

Comment 5 Matt McCutchen 2008-02-21 22:07:15 UTC
(In reply to comment #3)
> Is use chroot enabled by default so that commenting it out is not enough to
> disable it?

Yes.