>> 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 [...]
> chroot(8) is fundamentally broken, as it requires the executable to
> be inside the jail.

How is that "fundamentally broken"?  It's still plenty useful.  It's
useful for "chroot /trialroot /bin/sh", it's useful for what I want (if
I cared enough, my tiny executable would be outside the jail, and would
do the chroot(2) itself, rather than depending on chroot(8))....

chroot(8)'s spec is that it chroot(2)s (and chdir()s) and then execs.
Since exec fundamentally depends on pathnames, and pathname
interpretation has been changed (that's the whole point!), the
executable must perforce be in the new root.

If you don't like this, I invite you to suggest another way of doing
it.  I'd be interested to hear what you *don't* consider "fundamentally
broken".  (That is not sarcasm; it's entirely serious.  I'm always
interested in ideas that are new to me.)

					der Mouse

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