On Thu, 31 Oct 2002, David Laight wrote:

# -C ?
#
# You could always vfork and do the chroot in the child.....
# Alternatively root can move its chroot point...
#
# Actually netbsd chroot seems to have fixed the easy escape,
# can fchroot be used instead:
# 	fd = open("/",..);
# 	chroot(path);
# 	....
# 	fchroot(fd);

I just had a thought.  Presumably, the reason for not permitting chroot()
is that one could potentially hard link something like login or su into
their tree, provide their own password databases and gain root access via
a shell.  At least that was the rationale explained to me for not allowing
chroot() by normal users.

What if chroot() were to create/cause exec semantics such that, if not
called by a super-user, setuid/setgid would be ignored?

				--*greywolf;
--
NetBSD: It's not Windows (thank the gods for small favours).