>How about making namespace's as first class objects with some associated >name or device in the device tree having owner/permissions etc. any >process which forks off a namespace shall create the >device node for the namespace. If some other process wants to use >the same namespace, it can do so by attaching itself to the namespace >dynamically? Offcourse children processes inherit the same namespace.
For the issues being discussed here, I don't think that's materially different from what we started with; it has the same issue concerning whether a user should be allowed to change his namespace and whether a process' namespace should change automatically when another process does something. Here's one more proposal, kind of a compromise among various previous ones. - When you mount(), you say whether the names should be visible by default or not. It takes system privilege to make them visible by default, but an ordinary user can mount a willing filesystem over a directory he's permitted to modify unconditionally, invisible by default - A process can explicitly request to see an invisible-by-default mounted filesystem. Anyone can do this, but permissions on the root directory of the mount determine if he can actually see anything. - A process inherits the parent's namespace (i.e. sees the mounts the parent does). This accomplishes: - not much of a philosophical break from where we are now. - users can mount their own stuff without system privilege. - no one, not even a fully permitted administrative process, sees user junk by default. - setuid programs see standard files where the system administrator put them. - setuid programs see user files where the user put them. - multiple processes, with or without the same uid, can see user-mounted files if they want. - a process can opt not to see user-mounted files, even if it has the same uid as processes that do. I'm not saying how I would implement this; there's enough discussion over the desired result that I thought we should start there. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
