On Tue, Jul 11, 2006 at 09:46:01PM -0600, 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.
>
> 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.
well, here I'd definitely prefer to fix up that 'broken'
entries by adding proper capability checks, and maybe
even a bunch of new capabilities (i.e. 64bit caps and
such) first, because IMHO the capability system is the
'proper' method to protect them in the first place
> 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.
that's where file tagging as Linux-VServer does it can
be used to 'share' a partition between different guests
(and have separate disk limits and quotas)
best,
Herbert
> > Signed-off-by: Cedric Le Goater <[email protected]>
> > Cc: Andrew Morton <[email protected]>
> > Cc: Kirill Korotaev <[email protected]>
> > Cc: Andrey Savochkin <[email protected]>
> > Cc: Eric W. Biederman <[email protected]>
> > Cc: Herbert Poetzl <[email protected]>
> > Cc: Sam Vilain <[email protected]>
> > Cc: Serge E. Hallyn <[email protected]>
> > Cc: Dave Hansen <[email protected]>
> >
> > ---
> > fs/ioprio.c | 5 +
> > include/linux/init_task.h | 2
> > include/linux/nsproxy.h | 2
> > include/linux/sched.h | 6 +-
> > include/linux/user.h | 45 +++++++++++++++
> > init/Kconfig | 8 ++
> > kernel/nsproxy.c | 15 ++++-
> > kernel/sys.c | 8 +-
> > kernel/user.c | 135 ++++++++++++++++++++++++++++++++++++++++++----
>
> This patch looks extremly incomplete.
>
> 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.
>
> I think the key infrastructure needs to be looked at here as well.
>
> There needs to be a user namespace association for mounted filesystems.
>
> 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.
>
> A user namespace is a big thing. What I see here doesn't even
> seem to scratch the surface.
>
> Eric
-
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]
