Possible UID/GID bug in chrooted shells?

[Dave Dykstra]

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
for it.

- Dave Dykstra