From owner-freebsd-hackers Mon Feb 24 09:32:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02674 for hackers-outgoing; Mon, 24 Feb 1997 09:32:33 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA02653; Mon, 24 Feb 1997 09:32:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA24627; Mon, 24 Feb 1997 10:28:40 -0700 From: Terry Lambert Message-Id: <199702241728.KAA24627@phaeton.artisoft.com> Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments To: proff@iq.org (Julian Assange) Date: Mon, 24 Feb 1997 10:28:40 -0700 (MST) Cc: phk@critter.dk.tfs.com, hackers@freebsd.org, security@freebsd.org In-Reply-To: <199702241328.AAA10815@profane.iq.org> from "Julian Assange" at Feb 25, 97 00:28:33 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The primary reason chroot() is rarely used is because it is painful > to use. LD_CHROOT makes it very, very easy to use. That said, I > have absolutely no doubt chroot() is used more than LD_LIBRARY_PATH, > LD_PRELOAD, LD_IGNORE_MISSING_OBJECTS, LD_TRACE_LOADED_OBJECTS, > LD_BIND_NOW, LD_SUPPRESS_WARNINGS and LD_WARN_NON_PURE_CODE put > together. The chroot/shared library interaction is the only painful element in using chroot(). This should be "fixed" with a loopback mount, rather than by the granting of a path lookup exception. In general, the use of a NULL chroot vp in a proc struct to indicate a non-chroot'ed process to namei(), is a bad thing. This special case code should go (and if it did, so would LD_CHROOT's utility). This would leave each process running on its own root vnode, effectively, and by default that vnode would be the real root. To resolve the mount covering FS geometry change update problem (which is *NOT* resolved in the chroot case currently, and is kludge-resolved in the non-chrooted process by reevaluation of the root vnode in the case of a NULL chroot vnode), you would need to use a vnode pointer pointer for the chroot vnode, and an addref/release mechanism for the pointer pointer reference to the pointer so that a placeholder vnode that wasn't a mount point could be freed when its last reference went away. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.