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

[jw schultz]

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.



-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt