>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 think I misunderstood your proposal. >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. How does that address the setuid problem -- that a setuid program is installed with the expectation that when it runs, certain names will identify certain files (e.g. /etc/shadow)? But also that certain other names will identify a file of the invoker's choosing? >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? Essentially. It's a compromise. A user can customize his namespace, but only within limits that preserve the integrity of the system. Technically, we have to admit it's not one namespace today or with invisible mounts. Because of the way mounts cover up mountpoints, it's technically possible for two processes to see different files as the same name, if one opened the directory before a mount and the other after. "Mounting over" is a curse. -- 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
