Date: Sat, 15 Jul 2000 02:50:06 -0700 From: Julian Elischer <julian@elischer.org> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Dan Nelson <dnelson@emsphone.com>, Warner Losh <imp@village.org>, Adrian Chadd <adrian@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS Message-ID: <397033CE.446B9B3D@elischer.org> References: <Pine.NEB.3.96L.1000714235954.3234A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > > 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. These MAGIC symlinks are in fact cdevs inodes, not symlink inodes, with -1, -1 major minor, and the rest of the inode pointer space holding a symlink-like string. The string is ALWAYS interpretted as being based from the base of the device filesystem. In other words. it's a cdev, with normal permissions and ownerships etc., but instead of a major number and minor number, the connection to the driver is specified by the string. All old kernels would see an invalid cdev and return ENODEV. All rules that apply to making current CDEVS apply to these. > > 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 -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v 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?397033CE.446B9B3D>