Possible UID/GID bug in chrooted shells?
raq at worley.co.uk
Tue Jun 11 04:06:02 EST 2002
I'm stuck on a problem with rsync...
We've got a chrooted shell with rsync and all the needed libs inside (and not
We're using rsync over ssh to send the files into this chrooted session. The
rsync binary in the chrooted session is SUID root so that it can create the
files with the correct UID/GID. When the following is run, it creates all the
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 extracting
files from tar that belong to another user (that is the files inside the tar)
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 owned
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 creates
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. We'd
rather not have to setup users/passwords for several hundered users for rsync
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 files?
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,
Worley Web Solutions
More information about the rsync