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.
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.
Whoops, I meant "numeric ids = false". That one is easy to get backwards.
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...
(In reply to comment #3) > Is use chroot enabled by default so that commenting it out is not enough to > disable it? Yes.