Messages in this thread | | | Subject | Re: per-process namespace? | From | Ram Pai <> | Date | 30 Jun 2004 11:15:22 -0700 |
| |
On Wed, 2004-06-30 at 06:15, Mike Waychison wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > viro@parcelfarce.linux.theplanet.co.uk wrote: > > On Tue, Jun 29, 2004 at 05:10:21PM -0400, Mike Waychison wrote: > > > >>Another caveat is that the current system disallows you from doing any > >>mount/umount's in another namespace (bogus security?). > > > > > > Nothing bogus here - namespace boundary _IS_ a trust boundary and that's > > exactly the diference between symlinks and bindings - symlink attacks > > are possible exactly because they allow you to modify visible tree > topology > > for other users. > > Yet being able to access another namespace via directory fd still breaks > that boundary. I'm not sure if it's a feature or a not. If it is a > feature, I'd argue that having the fd means you are trusted to play in > that namespace, which implies the right to do things like call mount(2) > in it. > > > > > Note that sharing parts of namespace (which is basically what automounter > > wants and what we do not have yet) is deliberate act of trust - same as > > having a part of your address space shared with other process. > > Namespace sharing has been touched on before, but hasn't been discussed > publicly. My take on it is that in order to have namespace sharing work > in some semantically sane way, we need to be able to identify > owner-namespaces for shared branches of the vfsmount tree. This implies > making namespaces first-class primitives. Is this where we want to go > with this? > > I only see automounting being the only consumer of such a beast, are > there other possible users?
We have a customer requirement where they want to tailor the namespace of each process according to some environmental attributes. But at the same time they want to see the system mounts except at some predefined local directory tree.
The per-process namespace concept comes in handy here except for the static nature of the namespace. In the sense, any changes to the system namespace do not reflect in the children namespace.
Perhaps the way to implement this feature is to provide a feature to make some mounts points maskable.
A new forked-off namespace sees all the mounts in the parent namespace, except the mounts on mount point that are masked.
eager to hear how Al Viro envisions this to work, RP
> > - -- > Mike Waychison > Sun Microsystems, Inc. > 1 (650) 352-5299 voice > 1 (416) 202-8336 voice > http://www.sun.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: The opinions expressed in this email are held by me, > and may not represent the views of Sun Microsystems, Inc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFA4rzgdQs4kOxk3/MRAkxVAJ9kHj/6xfa/zSXLpT7v2hkOSFWhrgCggjL/ > ovcsxTkm6FpbWMlzIQn4geU= > =B4D5 > -----END PGP SIGNATURE----- >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |