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

[pyxl]

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"