From owner-freebsd-arch Sun Jul 16 0:41:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id AAC7137B546; Sun, 16 Jul 2000 00:40:55 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id BAA74519; Sun, 16 Jul 2000 01:40:54 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id BAA51827; Sun, 16 Jul 2000 01:40:34 -0600 (MDT) Message-Id: <200007160740.BAA51827@harmony.village.org> To: Brian Fundakowski Feldman Subject: Re: SysctlFS Cc: freebsd-arch@FreeBSD.org In-reply-to: Your message of "Sun, 16 Jul 2000 03:28:28 EDT." References: Date: Sun, 16 Jul 2000 01:40:34 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Brian Fundakowski Feldman writes: : On Sat, 15 Jul 2000, Warner Losh wrote: : : > : Why? It's got exactly the same considerations as the "true" root being : > : able to mount(2) things into a jail or mknod(2). : > : > You shouldn't be able to mount thinks in jail or mknod. While in : > jail, you cannot do a mknod right now. While in jail, you can't do a : > mount. : > : > Creating holes in this scheme makes me extremely nervous. : : Exactly! The same permissions would apply to this form of symlink : as those which apply to mknod and mount in jails. But this sort of thing is potentially worse. If you can follow the symlink out of jail, can you use it to get to other files? The only way that device nodes exist in the jail now is if the jailors create them for the Jail. Ditto with mount points. Ditto with this. I'm sure that any sort of automatic adding of device nodes to a jail'd process' space is wrong by default. All things that aren't explicitly permitted are forbidden. : > : > Also, you really don't want too many devices in a jail's /dev tree. : > : > You really wouldn't want devfs for jail unless you could limit it : > : > severely. And that's going to be hard to write, I think. : > : : > : But you could create multiple mounts (instances) of devfs which each : > : contain a specific subset of the devfs proper and do the "symlink : > : breakout" accordingly :) An aspect of jail classes, if you will. : > : > Why bother with a symlink? Why not have a reference to the real : > dev_t? : : The dev_t of what, exactly? The device that the jailed process can access. Right now we put the dev_t in the hierarchy of the jailed process, which is the userland dev_t. With a devfs implementation, you could put the kerneland dev_t into the filesystem generally. If you do that, then you'll need to do that in jail as well. If you don't, mknod is suffient for jailed processes, plus maybe with a major number lookup routine (kernel, tell me what the major number for wd). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message