Re: [PATCH -mm 5/7] add user namespace

[Cedric Le Goater <clg@fr.ibm.com>]

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/