Possible UID/GID bug in chrooted shells?

tim.conway at philips.com tim.conway at philips.com
Tue Jun 11 09:28:02 EST 2002

Tom:  You just need to tell rsync to use numeric IDS, or else make a /etc 
in the chroot root, so that names can be resolved (it's chrooted, so it 
can't see the real /etc... ever notice the /etc in anon ftp sessions?). By 
default, rsync uses the names, rather than the numbers, since it was 
developed as a mirroring tool, where you might be mirroring a system where 
the ids don't match.  If it's not told to use numeric ids, it will attempt 
to resolve names to local numeric ids, and use them, else it uses the euid 
and egid of the rsync process.

SunOS 5.7           Last change: 25 Jan 2002                    5

User Commands                                            rsync(1)

          --numeric-ids           don't map uid/gid values by user/group 

Tim Conway
tim.conway at philips.com
303.682.4917 office, 3039210301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn, 
".\n" '
"There are some who call me.... Tim?"

Tom Worley <raq at worley.co.uk>
Sent by: rsync-admin at lists.samba.org
06/11/2002 05:01 AM
Please respond to raq

        To:     rsync at lists.samba.org
        cc:     (bcc: Tim Conway/LMT/SC/PHILIPS)
        Subject:        Possible UID/GID bug in chrooted shells?

I'm stuck on a problem with rsync...
We've got a chrooted shell with rsync and all the needed libs inside  (and 
much else). 
We're using rsync over ssh to send the files into this chrooted session. 
rsync binary in the chrooted session is SUID root so that it can create 
files with the correct UID/GID. When the following is run, it creates all 
files as root.staff, not as the test user/group, or the correct UID/GID of 

the original files, so the SUID root is working. We've also tried 
files from tar that belong to another user (that is the files inside the 
and when tar is suid root in the chroot it extracts them with the correct 
This is the command we used:
rsync --delete-excluded --delete -essh -avz /home/admin/ 
test at localhost:/home/backup
(from outside the chroot, the "test" user being inside it)

The test user's shell is the chrooted session, and the session works fine 
through ssh, rsync runs without errors, but all the files created are 
by root.
If we try the same but to a non-chrooted user (and suid root to the rsync 
binary outside the chroot, yeah yeah, it's just a test), it correctly 
the files with the right UID/GID. I've even tried copying the complete 
/etc/passwd and shadow files into the chroot jail, but that didn't help. 
rather not have to setup users/passwords for several hundered users for 
and run it as a daemon (and send the password securely somehow to each 
person).  Could it be a bug in the way rsync sets the UID/GID of the 
Running Debian Linux Sid, up to date as of this morning, and rsync:
rsync  version 2.5.6cvs  protocol version 26 from debian packages.
Kind regards, and TIA,
Tom Worley
Worley Web Solutions

To unsubscribe or change options: 
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

More information about the rsync mailing list