I'm stuck on a problem with rsync... We've got a chrooted shell with rsync and all the needed libs inside (and not much else). 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 UID/GID. This is the command we used: rsync --delete-excluded --delete -essh -avz /home/admin/ test@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 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 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, Tom Worley Worley Web Solutions http://www.worleyweb.net http://www.uk2raq.com http://www.totalannihilation2.com http://projectmist.org
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 name Tim Conway tim.conway@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, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), ".\n" ' "There are some who call me.... Tim?" Tom Worley <raq@worley.co.uk> Sent by: rsync-admin@lists.samba.org 06/11/2002 05:01 AM Please respond to raq To: rsync@lists.samba.org cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject: Possible UID/GID bug in chrooted shells? Classification: I'm stuck on a problem with rsync... We've got a chrooted shell with rsync and all the needed libs inside (and not much else). 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 UID/GID. This is the command we used: rsync --delete-excluded --delete -essh -avz /home/admin/ test@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 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 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, Tom Worley Worley Web Solutions http://www.worleyweb.net http://www.uk2raq.com http://www.totalannihilation2.com http://projectmist.org -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
On 12 Jun 2002, Tom Worley <tom@worley.co.uk> wrote:> Dear Martin, > Sorry to mail you directly, but I've had no joy trying to get round this > problem (read the faqs, posted on the mailing list RTFM a lot etc) > This is (slightly updated) what I posted to the mailing list: > I'm stuck on a problem with rsync... > We've got a chrooted shell with rsync and all the needed libs inside (and not > much else). > 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 > UID/GID. > This is the command we used: > rsync --delete-excluded --delete -essh -avz --numeric-ids /home/admin/ > test@localhost:/home/backup > (from outside the chroot, the "test" user being inside it) > > The test user's shell is the chrooted session,What do you mean by that? Their /etc/passwd shell is some "chrooted session" program? If you wrote it please post the source, otherwise what is the name. Do you know you cannot just run /usr/sbin/chroot as a regular user? It's a privileged operation; it must be done before changing uid.> and the session works fine through ssh, rsync runs without errors, > but all the files created are owned 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 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, linux > 2.4.18 kernel, chroot 2.0.11 on an i686. > Kind regards, and TIA, > Regards, > Tom Worley-- Martin
On 13 Jun 2002, Tom Worley <tom@worley.co.uk> wrote:> On Thursday 13 June 2002 5:40 am, Martin Pool wrote: > > What do you mean by that? Their /etc/passwd shell is some "chrooted > > session" program? If you wrote it please post the source, otherwise > > what is the name. > Setup as described here: > http://tjw.org/chroot-login-HOWTO/ > (but with only the libs required for rsync, bash and su) > Basically the shell is a wrapper that runs chroot (using sudo privaledges) > then su -'s to the user inside the chrootAnd does that actually work with ssh when a command is passed? What does ssh luser@localhost id ssh luser@localhost pwd show? (You will need to install those commands into the jail.) -- Martin