Possible UID/GID bug in chrooted shells?
dwd at bell-labs.com
Thu Jun 13 11:34:12 EST 2002
On Tue, Jun 11, 2002 at 06:05:37PM +0100, Tom Worley wrote:
> On Tuesday 11 June 2002 5:24 pm, you wrote:
> > 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.
> > --numeric-ids don't map uid/gid values by user/group
> Tim, I had already tried that with no joy, e.g.:
> rsync --delete-excluded --delete -essh -avzog --numeric-ids /home/admin/
> test at localhost:/home/backup
> Same results, all files are owned by root as rsync is SUID root in the chroot
> enviroment. There is an /etc/passwd in there, but only with root and the test
> user's entries.
> Oh, and I'm using linux 2.4.18 kernel, chroot 2.0.11, rsync 2.5.6CVS (from
> debian sid packages)
rsync is not designed to run setuid-root so I'm not surprised that it
behaves strangely. It might help to write a small setuid-root wrapper
program that sets the real user id to root and execs rsync.
In general it's a bad idea to make a program setuid if it isn't designed
- Dave Dykstra
More information about the rsync