From owner-freebsd-arch Sat Jul 15 2:50:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 2E42B37B5C3; Sat, 15 Jul 2000 02:50:29 -0700 (PDT) (envelope-from julian@elischer.org) Received: from bissau-16.budapest.interware.hu ([195.70.53.144] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13DOaY-0000rQ-00; Sat, 15 Jul 2000 11:50:27 +0200 Message-ID: <397033CE.446B9B3D@elischer.org> Date: Sat, 15 Jul 2000 02:50:06 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Robert Watson Cc: Dan Nelson , Warner Losh , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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