Date: Sat, 15 Jul 2000 16:00:59 -0400 (EDT) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Adrian Chadd <adrian@FreeBSD.ORG> Cc: Julian Elischer <julian@elischer.org>, Kelly Yancey <kbyanc@posi.net>, Robert Watson <rwatson@FreeBSD.ORG>, Dan Nelson <dnelson@emsphone.com>, Warner Losh <imp@village.org>, freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS Message-ID: <Pine.BSF.4.21.0007151542040.877-100000@green.dyndns.org> In-Reply-To: <20000715140614.A22865@ywing.creative.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007151542040.877-100000>