rsync - Jun 2002 - documentation bug for --daemon "use chroot" in conjunction with -o and -g

Hi all,

Tripped over a documentation bug.  I'm guessing the behavior I've found 
isn't a bug in itself as it's kind of implied by chroot (unless the 
/etc/passwd db is read *before* you do the chroot call), so I'm calling 
it a documentation bug.

The Setup:

System A:  running rsync --daemon from xinetd, configured with a 
read-only share.
System B:  syncing a local directory structure from the share on System A.
Both running Red Hat Linux 7.2, and rsync 2.5.4

The Problem:

The documentation indicates that -o and -g on the client side preserve 
the user and group of the files/dirs transferred as compared by name 
(i.e. for sync A=>B, if the uid for "bob" is 205 on A, and 3328 on
B,
then the uid of the file will be converted transparently to 3328 on B 
during a sync).  HOWEVER, what isn't mentioned in the man page for 
either rsync or rsyncd.conf is that for the -o and -g options to work, 
the server side MUST have "use chroot = no" in the config file.  As
the
default behavior for rsync is "use chroot = yes", this can make things
frustrating when the directions and the behavior don't quite sync (pun 
gleefully intended) up.  It ends up setting the uid and gid to the 
numeric ids from the server side, which is functionally equivalent to 
using --numeric-ids (with variations based on what user the client side 
is running as).

The Solution:

Mention on the rsync man page in the -o and -g descriptions that syncing 
from a --daemon based share requires that "use chroot = no" be
specified
in the rsyncd.conf, and mention on the rsyncd.conf man page that if "use 
chroot = no" isn't specified in the rsyncd.conf that -o and -g will not
work on the client side.

Thanks for your attention,

Scott

pyxl wrote:
> Hi all,
> 
> Tripped over a documentation bug.  I'm guessing the behavior I've
found
> isn't a bug in itself as it's kind of implied by chroot (unless the
> /etc/passwd db is read *before* you do the chroot call), so I'm calling
> it a documentation bug.
I pointed out the same thing a few months ago.

I believe I was told that its in the documentation, I just needed to 
know where to look.

The reason it fails is that if chroot is used, the system can no longer 
access /etc/passwd (since / has changed)...

I spent hours adding debug and such all over the code to try and find 
where it wasn't mapping the uid's.

Well,

Looking at the source for 2.5.5, I'm only seeing mention of it under the
--numeric-ids
flag in rsync(1); --owner doesn't make mention of it at all.  What you
quoted must be
in CVS (I'd look, but I don't know how to do a remote CVS checkout yet,
and am too
lazy to learn at this moment).

Here's a patch for the changes to those man pages against the 2.5.5 release
tree.
It changes --owner in rsync(1) and "use chroot" in rsyncd.conf(5).

diff -uNr rsync-2.5.5/rsync.1 rsync-2.5.5_update/rsync.1
--- rsync-2.5.5/rsync.1	Wed Feb  6 16:21:19 2002
+++ rsync-2.5.5_update/rsync.1	Tue Jun 25 16:28:52 2002
@@ -488,7 +488,9 @@
 .IP "\fB-o, --owner\fP" 
 This option causes rsync to set the owner of the
 destination file to be the same as the source file\&.  On most systems,
-only the super-user can set file ownership\&.  
+only the super-user can set file ownership\&.  For this to work when one
+side is an rsync daemon, the module must be configured with "use chroot =
no"
+or else only numeric uid and gid will be provided\&.
 .IP 
 .IP "\fB-g, --group\fP" 
 This option causes rsync to set the group of the
diff -uNr rsync-2.5.5/rsyncd.conf.5 rsync-2.5.5_update/rsyncd.conf.5
--- rsync-2.5.5/rsyncd.conf.5	Fri Aug 31 04:12:35 2001
+++ rsync-2.5.5_update/rsyncd.conf.5	Tue Jun 25 16:46:51 2002
@@ -144,7 +144,9 @@
 of not being able to follow symbolic links outside of the new root path
 when reading\&.  When "use chroot" is false, for security reasons
 symlinks may only be relative paths pointing to other files within the
-root path, and leading slashes are removed from absolute paths\&.  The
+root path, and leading slashes are removed from absolute paths\&.  Note
+that for --owner (-o) and --group (-g) client side options to function,
+"use chroot" must be set to false for the module\&.  The
 default for "use chroot" is true\&.
 .IP 
 .IP "\fBmax connections\fP" 

I'll attach it as a file as well.

Scott



On Mon, Jun 24, 2002 at 12:24:20PM -0400, pyxl wrote:
> Well, it's definitely not in either of the man pages - and those should
> be the canonical documentation of rsync's behavior.  But it's a
small
> bug (with big teeth!).
> 
> Corey Stup wrote:
> 
> > pyxl wrote:
> >
> >> Hi all,
> >>
> >> Tripped over a documentation bug.  I'm guessing the behavior
I've
> >> found isn't a bug in itself as it's kind of implied by
chroot (unless
> >> the /etc/passwd db is read *before* you do the chroot call), so
I'm
> >> calling it a documentation bug.
I wouldn't suggest trying to preload the password database.
The password and group "databases" can easily be comming
from multiple sources (nis, ldap, pam, ...) and can have
tens of thousands of entries.
> >
> >
> > I pointed out the same thing a few months ago.
> >
> > I believe I was told that its in the documentation, I just needed to 
> > know where to look.
> >
> > The reason it fails is that if chroot is used, the system can no 
> > longer access /etc/passwd (since / has changed)...
> >
> > I spent hours adding debug and such all over the code to try and find 
> > where it wasn't mapping the uid's.
It is "documented" in the rsync(1) manpage in two places.

under --owner:
      Note that if the source system is  a daemon  using
      chroot, the --numeric-ids option is implied because
      the source system cannot get access  to the  user?
      names.

and again under --numeric-ids:
      If the source system is a daemon using chroot, or if
      a user or group name does not exist on the des?
      tination system, then  the  numeric id  from  the
      source system is used instead.

I agree it could do with a mention in rsyncd.conf(5) under
"use chroot".

I also wonder about the accuracy of the entries in rsync(1).
It seems to me that it wouldn't matter whether the chrooted
daemon is the source or the destination.

Despite the increasing use of chroot by daemons, the
percentage of sysadmins who understand the implications of
chroot is steadily declining and we shouldn't expect rsync
users to be experts.

I'm inclined to think that the chroot(1) and chroot(2)
manpages really should do a better job of covering this
issue.  It isn't just passwd, there are a whole host of
issues related to the loss of /etc /bin and paths for ld.so
that will seem obscure to anyone who hasn't had to manually
configure annonymous ftp.

In any event.  Since both of you have recently experienced
this as a problem you are best qualified to propose
_specific_ patchs to the manpages that might help others
like yourselves.  Please try to be brief as manpages should
not be tutorials.


-------------- next part --------------
diff -uNr rsync-2.5.5/rsync.1 rsync-2.5.5_update/rsync.1
--- rsync-2.5.5/rsync.1	Wed Feb  6 16:21:19 2002
+++ rsync-2.5.5_update/rsync.1	Tue Jun 25 16:28:52 2002
@@ -488,7 +488,9 @@
 .IP "\fB-o, --owner\fP" 
 This option causes rsync to set the owner of the
 destination file to be the same as the source file\&.  On most systems,
-only the super-user can set file ownership\&.  
+only the super-user can set file ownership\&.  For this to work when one
+side is an rsync daemon, the module must be configured with "use chroot =
no"
+or else only numeric uid and gid will be provided\&.
 .IP 
 .IP "\fB-g, --group\fP" 
 This option causes rsync to set the group of the
diff -uNr rsync-2.5.5/rsyncd.conf.5 rsync-2.5.5_update/rsyncd.conf.5
--- rsync-2.5.5/rsyncd.conf.5	Fri Aug 31 04:12:35 2001
+++ rsync-2.5.5_update/rsyncd.conf.5	Tue Jun 25 16:46:51 2002
@@ -144,7 +144,9 @@
 of not being able to follow symbolic links outside of the new root path
 when reading\&.  When "use chroot" is false, for security reasons
 symlinks may only be relative paths pointing to other files within the
-root path, and leading slashes are removed from absolute paths\&.  The
+root path, and leading slashes are removed from absolute paths\&.  Note
+that for --owner (-o) and --group (-g) client side options to function,
+"use chroot" must be set to false for the module\&.  The
 default for "use chroot" is true\&.
 .IP 
 .IP "\fBmax connections\fP"