Messages in this thread | | | Date | Wed, 12 Jul 2006 16:00:40 +0200 | From | Cedric Le Goater <> | Subject | Re: [PATCH -mm 5/7] add user namespace |
| |
Eric W. Biederman wrote: > Cedric Le Goater <clg@fr.ibm.com> writes: > >> This patch adds the user namespace. >> >> Basically, it allows a process to unshare its user_struct table, >> resetting at the same time its own user_struct and all the associated >> accounting. >> >> For the moment, the root_user is added to the new user namespace when >> it is cloned. An alternative behavior would be to let the system >> allocate a new user_struct(0) in each new user namespace. However, >> these 0 users would not have the privileges of the root_user and it >> would be necessary to work on the process capabilities to give them >> some permissions. > > It is completely the wrong thing for a the root_user to span multiple > namespaces as you describe. It is important for uid 0 in other namespaces > to not have the privileges of the root_user. That is half the point.
ok good. that's what i thought also.
> Too many files in sysfs and proc don't require caps but instead simply > limit things to uid 0. Having a separate uid 0 in the different namespaces > instantly makes all of these files inaccessible, and keeps processes from > doing something bad.
but in order to be useful, the uid 0 in other namespaces will need to have some capabilities.
> To a filesystem a uid does not share a uid namespace with the only things > that should be accessible are those things that are readable/writeable > by everyone. Unless the filesystem has provisions for storing multiple > uid namespaces not files should be able to be created. Think NFS root > squash.
I think user namespace should be unshared with filesystem. if not, the user/admin should know what is doing.
> Every comparison of a user id needs to compare the tuple > (user namespace, user id) or it needs to compare struct users. > > Ever comparison of a group id needs to compare the tuple > (user namespace, group id) or it needs to compare struct users.
yes, that would be the ultimate user namespace.
I think that this first patchset lays some infrastructure that is already quite usable in a container which already isolates file, pids, etc and not only users.
now, we could work on extending it to support fine grain user namespace which i think can done on top of this first patch.
> I think the key infrastructure needs to be looked at here as well. > > There needs to be a user namespace association for mounted filesystems.
yes you could expect that to check the i_uid against fsuid but should we enforce it completely ?
we already have an issue today with a simple NFS mount on 2 hosts with different user mapping. namespace can't fix all issues.
> We need a discussion about how we handle map users from one user > namespace to another, because without some form of mapping so many > things become inaccessible that the system is almost useless. > > I believe some of the key infrastructure which is roughly kerberos > authentication tokens could be used for this purpose.
please elaborate ? i'm not sure to understand why you want to use the keys to map users.
> A user namespace is a big thing. What I see here doesn't even > seem to scratch the surface.
good let's start digging !
thanks,
C. - 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/
| |