I am using rsync 2.5.5 running as a daemon on the destination system, which is SuSE Linux 8.0. The source system is SuSE 7.3, also with rsync 2.5.5. With the default 'use chroot = true' and not using --numeric-ids, I get the wrong user names on the destination files. I have tracked this down to getpwnam() failing to return the user name from the passwd file. It does not fail when chroot() is not called ( by setting 'use chroot = false' in rsyncd.conf). A simple test program calling chroot() followed by getpwnam() shows the same effect, so the problem is not really in rsync. As I wasted quite a lot of time discovering this, it could be helpful to put a warning in the documentation of rsync. For some reason errno is zero on return from getpwnam() in the above case, although in my test program it is set to 29 (no such file or directory). It would therefore not be very useful to test errno in the rsync code. Regards Riq Willitts Technical Director Scientific Computing Service Ltd.
On Thu, Sep 19, 2002 at 10:02:18AM +0100, Riq Willitts wrote:> I am using rsync 2.5.5 running as a daemon on the destination system, which > is SuSE Linux 8.0. The source system is SuSE 7.3, also with rsync 2.5.5. > With the default 'use chroot = true' and not using --numeric-ids, I get > the wrong user names on the destination files. I have tracked this down to > getpwnam() failing to return the user name from the passwd file. It does > not fail when chroot() is not called ( by setting 'use chroot = false' in > rsyncd.conf). > > A simple test program calling chroot() followed by getpwnam() shows the > same effect, so the problem is not really in rsync. > > As I wasted quite a lot of time discovering this, it could be helpful to > put a warning in the documentation of rsync. > > For some reason errno is zero on return from getpwnam() in the above case, > although in my test program it is set to 29 (no such file or directory). It > would therefore not be very useful to test errno in the rsync code.Because too many people no longer seemed to understand the implications of chroot this has already been done in CVS. The rsyncd.conf.5 manpage specifically mentions this under the "use chroot" directive. it has the disadvantages of ... implying the --numeric-ids option because /etc/passwd becomes inaccessible. It is also specified in rsync.1 under --owner On most systems, only the super-user can set file ownership. Note that if the remote system is a daemon using chroot, the --numeric-ids option is implied because the remote system cannot get access to the usernames from /etc/passwd. And again under --numeric-ids The bases are pretty well covered. Thanks for the thought. It just hasn't yet made it into a released version. Once it is it will take a few months to get into the packaged distributions. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt
Thank you for the prompt and clear reply. That should settle the matter. At 02:41 19/09/02 -0700, you wrote:>On Thu, Sep 19, 2002 at 10:02:18AM +0100, Riq Willitts wrote: > > I am using rsync 2.5.5 running as a daemon on the destination system, > which > > is SuSE Linux 8.0. The source system is SuSE 7.3, also with rsync 2.5.5. > > With the default 'use chroot = true' and not using --numeric-ids, I get > > the wrong user names on the destination files. I have tracked this > down to > > getpwnam() failing to return the user name from the passwd file. It does > > not fail when chroot() is not called ( by setting 'use chroot = false' in > > rsyncd.conf). > > > > A simple test program calling chroot() followed by getpwnam() shows the > > same effect, so the problem is not really in rsync. > > > > As I wasted quite a lot of time discovering this, it could be helpful to > > put a warning in the documentation of rsync. > > > > For some reason errno is zero on return from getpwnam() in the above case, > > although in my test program it is set to 29 (no such file or > directory). It > > would therefore not be very useful to test errno in the rsync code. > >Because too many people no longer seemed to understand the >implications of chroot this has already been done in CVS. > >The rsyncd.conf.5 manpage specifically mentions this under the >"use chroot" directive. > > it has the disadvantages of ... implying the > --numeric-ids option because /etc/passwd becomes > inaccessible. > >It is also specified in rsync.1 under --owner > > On most systems, only the super-user can set file > ownership. Note that if the remote system is a > daemon using chroot, the --numeric-ids option is > implied because the remote system cannot get access > to the usernames from /etc/passwd. > >And again under --numeric-ids > >The bases are pretty well covered. Thanks for the thought. > >It just hasn't yet made it into a released version. Once it >is it will take a few months to get into the packaged >distributions. > > > >-- >________________________________________________________________ > J.W. Schultz Pegasystems Technologies > email address: jw@pegasys.ws > > Remember Cernan and Schmitt >-- >To unsubscribe or change options: >http://lists.samba.org/mailman/listinfo/rsync >Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.htmlRegards Riq Willitts Technical Director Scientific Computing Service Ltd.