Date: Sat, 15 Jul 2000 00:04:08 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Dan Nelson <dnelson@emsphone.com> Cc: Julian Elischer <julian@elischer.org>, Warner Losh <imp@village.org>, Adrian Chadd <adrian@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS Message-ID: <Pine.NEB.3.96L.1000714235954.3234A-100000@fledge.watson.org> In-Reply-To: <20000714170824.A21158@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Jul 2000, Dan Nelson wrote: > Would it be possible to have a symbolic link type that breaks out of a > jail? So you would have a "/myjail/dev ->> /dev" link in the jail that > ends up referring to the real /dev. This would also fix the /proc > problem. You wouldn't want to link /myjail/usr/lib to /usr/lib, > though, because the jailed root would be able to modify the binaries, > but /dev and /proc seem safe. The real problem is determining what the symlink would be relative to. When performing a name-lookup for a process, there are two possible starting vnodes -- the process's root vnode (paths prefixed with /), and the process's cwd vnode (w/o a / at the beginning). Symlinks restart evaluation, and if prefixed with a "/", restart at the process's root vnode. If you had one of these "magic" symlinks, how would it know what vnode to start evaluating from? Especially in diskless nested environments mounted out of an MFS root during boot, there is no one true root. You could imagine a light-weight mountpoint technique based on a special form of symlink, where the mountpoint is stared in the file system, instead of in the kernel mount table. When such a symlink was hit, it would be auto-followed. This is a lot like the behavior in Coda and AFS, where mountpoints are actually symlinks to #volumename, only in that environment, the protection model is compatible with that. You could imagine symlinks to specific synthetic file systems, including #system.procfs and #system.sysctlfs. When hit during a namei, it could either be turned into a real vnode mountpoint, or follow into a special table namespace. Of course, unless protected appropriately, this would create new risks as you chouldn't prevent a jail from accessing /proc. A light-weight mount mechanism might make a lot of sense, though, especially if based on a volume mechanism. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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.NEB.3.96L.1000714235954.3234A-100000>