From owner-freebsd-arch Sat Jul 15 13: 1: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3885B37BA05; Sat, 15 Jul 2000 13:01:01 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 15 Jul 2000 16:00:59 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Adrian Chadd Cc: Julian Elischer , Kelly Yancey , Robert Watson , Dan Nelson , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS In-Reply-To: <20000715140614.A22865@ywing.creative.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'll probably get flamed badly for this proposition, but here goes :) We could create a way for jailed processes to "break out" into the canonical name space. This is a description of possible semantics for creating these "breakout" symlinks, which seems (to me at least) quite feasible. One, a special capability to create these special symlinks would be given to, for now, root outside of any jails. That's a given. The symlinks would point to a place that begins with two slashes to signify "canonical root". That is: # cd /home/jails/foojail # ln -s //proc # ls -l proc lwrxr-xr-x 1 root wheel 6 Jul 15 15:49 proc -> //proc Users without this capability would get the familiar EPERM, including everyone inside a jail. This would be treated by namei(), when inside a jail, with immutable semantics (and not seen as a symlink). Of course, .. would be treated as referring to the jailed root. So inside the jail, you would see: foojail# ls -ld /proc /proc/.. / drwxr-xr-x 37 root wheel 1024 Jul 13 05:29 / dr-xr-xr-x 1 root wheel 512 Jul 15 15:53 /proc drwxr-xr-x 37 root wheel 1024 Jul 13 05:29 /proc/.. The advantages of this would be that it wouldn't be very hard to implement (doesn't touch that much code), justifiable implementation (everyone in the world should know by now that "//" isn't going to be "/" on every system), and clear semantics. The only disadvantage I see would be to make an already complex namei() more complex; I believe it wouldn't add much more complexity, though. I think it is a reasonable solution :) Of course, process-based mount tables would be nice... ;) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message