On Wed, 2005-04-20 at 17:42, Bryan Henderson wrote:
> >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?

the new namespace 'n1' though created by the user 'ram', carries the
same restrictions to 'ram' . So 'ram' will not be able to mount
something else on /bin or /sbin or anyother directory that it does not
own, even though its done in its own namespace. Hence I dont see how a
attacker would be able fool a malicious setuid program into a genuine
setuid program. hope this is the concern you were talking about. right?

RP


> 
> >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

Reply via email to