Messages in this thread | | | Subject | Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag | From | Miklos Szeredi <> | Date | Wed, 18 Apr 2007 11:19:46 +0200 |
| |
> > Allowing this and other flags to NOT be propagated just makes it > > possible to have a set of shared mounts with asymmetric properties, > > which may actually be desirable. > > The shared mount feature was designed to ensure that the mount remained > identical at all the locations.
OK, so remount not propagating mount flags is a bug then?
> Now designing features to make it un-identical but still naming it > shared, will break its original purpose. Slave mounts were designed > to make it asymmetric.
What if I want to modify flags in a master mount, but not the slave mount? Would I be screwed? For example: mount is read-only in both master and slave. I want to mark it read-write in master but not in slave. What do I do?
> Whatever feature that is desired to be exploited; can that be exploited > with the current set of semantics that we have? Is there a real need to > make the mounts asymmetric but at the same time name them as shared? > Maybe I dont understand what the desired application is?
I do think this question of propagating mount flags is totally independent of user mounts.
As it stands, currently remount doesn't propagate mount flags, and I don't see any compelling reasons why it should.
The patchset introduces a new mount flag "allowusermnt", but I don't see any compelling reason to propagate this flag _either_.
Please say so if you do have such a reason. As I've explained, having this flag set differently in parts of a propagation tree does not interfere with or break propagation in any way.
Miklos
- 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/
| |