On Wed, 2005-04-20 at 11:57, Bryan Henderson wrote: > >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. Well I am not aware of issues that can arise if a user is allowed to change to some namespace for which it has permission to switch. I am wondering what can those be. Just for clarity under the assumption that there wont be any security issues with this proposal, I will run through a typical case on how this proposal can be used to solve the FUSE needs. Ok let me explain how my proposal attempts to solves the problem: A user 'ram' creates a namespace 'n1' with a device node /dev/n1 having permission 700 owned by the user 'ram'. The user than tailors his namespace with a bunch of mount/umount/binds etc to meet his requirement. All the processes that fork off this process see this same setup. Now 'ram' again logs-in to the same machine from a different terminal. He gets the default system-namespace to begin with. But he runs a shell built-in command 'chnamespace n1' and hence forth it will hook on to the new namespace and see the same environment as seen by the other login. And this login can be automated to see the 'n1' namespace by default by making the login process to pick the 'n1' namespace right from the beginning (if one exists) by looking at the some configuration file like /etc/password or maybe /etc/shadow. Any other user who wants to attach to the same namespace can try to, but if the permissions are denied it wont be able to. > > 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). Trying to understand your proposal to see how it could be used to solve the problem faced by the FUSE project. Are you trying to use a single namespace with invisible mounts capability? RP > > 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
