Herbert Poetzl <[email protected]> writes:
> 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
I guess the good way to think of some of this is not as broken files.
But rather in the plan9 model. Initially everything on the machine is
owned by one user (in our case root). That user then controls who
else gets access to files by calling chown etc.
If you want access to those files in a different uid namespace someone
needs to call chown or at least chmod on them, and I'm not
at all certain this as a problem is limited to special files on
a filesystem.
Really when you do a proper user namespace this all comes for free.
>> 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)
I completely agree we need a capability like that. I disagree on the
implementation because it is not general. What we have really hit is
the classic uid mapping problem that shows up occasionally with
network filesystems. That is the problem we need to solve.
I'm pretty certain the current kernel key infrastructure gives us the
infrastructure we need to do that in a general way. At which point
it would be a policy decision which uid to map to which other uid
and we could easily match the current
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]
