Date: Sun, 16 Jul 2000 01:40:34 -0600 From: Warner Losh <imp@village.org> To: Brian Fundakowski Feldman <green@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: SysctlFS Message-ID: <200007160740.BAA51827@harmony.village.org> In-Reply-To: Your message of "Sun, 16 Jul 2000 03:28:28 EDT." <Pine.BSF.4.21.0007160327310.82825-100000@green.dyndns.org> References: <Pine.BSF.4.21.0007160327310.82825-100000@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0007160327310.82825-100000@green.dyndns.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007160740.BAA51827>