>> So, I was thinking, "why doesn't [chroot] presently [work for
>> non-uid=0]?".  The only reason I can see is that if the user has (or
>> can create) a writeable directory on the same filesystem as certain
>> set-id executables, it becomes really easy to leverage privilege.
> I believe the restriction was to prevent users creating their own
> /etc/passwd etc.

Right, that's what I was calling "really easy to leverage privilege".

>> It would also make escaping from a chroot jail easier.
> By using r* back to the same box after gaining another user's id?
> or did you have something else in mind?

Something else - the only ways out of a chroot jail I know of depend on
already having a file descriptor open on a directory outside the jail.
Assuming you're in the jail without such an fd, it is possible to
create such a situation if you can chroot to a subdirectory within the
jail.  As it stands, that requires cracking root within the jail....

> I hate having to start proxies as root _just_ so they can chroot(2).

Yeah...I tend to use chroot(8) to do the chroot, then have a tiny
program in the new root that does setuid() and execs the relevant
binary.  That way there doesn't need to be any untrusted code run as
root, it's chrooted, and in some cases there can even be no set-id
programs accessible in the jail....

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B