Eric W. Biederman wrote:
> Cedric Le Goater <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
