On Thu, 23 Jan 2003, David Young wrote:

[DY: Does chroot(2) require super-user privileges so that you cannot fool a
[DY: setuid program such as passwd into reading or writing a different file
[DY: than /etc/passwd ? Is there any other reason?

This is precisely why chroot(2) is disallowed to a mortal, only more so.

Consider:

	normal user a creates, say, a hierarchy under a mysteriously
writable directory under the root filesystem, creating a hard link from
/usr/bin/su to, say, /bogusdir/usr/bin/su.

	said user manages to write his own copy of /etc/master.passwd
with, say, root's encrypted passwd string removed.

	said user makes an exec wrapper:

main(){setuid(geteuid());seteuid(geteuid());execl("/bin/sh","-sh",0);}

	...compiles it and puts it in as /bogusdir/bin/hole.

	chroot is not restricted.  User chroots into /bogusdir, runs
/usr/bin/su.  Bingo.  No password.  He is now root.

	User makes /bin/hole mode 4555, owner root.

	User exits from root shell.

	User exits from chrooted environment.

Guess what lives at /bogusdir/bin/hole now?

[DY: Put another way, under what conditions is it safe for a non-root user
[DY: to chroot(2)?

This falls into the same category of "Under what conditions is it safe to
point a loaded gun at oneself?", really.

You would need to disallow set-id execution (and, arguably, device
access.)  The effects of this are left as an exercise for the
practitioner.

				--*greywolf;
--
Hack on NetBSD, and your code runs on over 40 architectures.