Hello Serge,
In 2.6.23-rc, your patch to add support for CLONE_NEWUSER is included. Is
there there some for-userland-programmers documentation of this flag
somewhere? Would you be able to send some documentation to me (ideally as
a patch to the clone.2 man page, but otherwise some plain text will do).
If this flag is also supported for unshare(), then could you please send me
a patch/text for that too?
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.
Michael Kerrisk <[email protected]> writes:
> Hello Serge,
>
> In 2.6.23-rc, your patch to add support for CLONE_NEWUSER is included. Is
> there there some for-userland-programmers documentation of this flag
> somewhere? Would you be able to send some documentation to me (ideally as
> a patch to the clone.2 man page, but otherwise some plain text will do).
>
> If this flag is also supported for unshare(), then could you please send me
> a patch/text for that too?
Currently this namespace is a work in progress marked with CONFIG_EXPERIMENTAL
because it is very much still experimental and under development.
There may be other omissions but the one I am most aware of is that
the in kernel user and group equality comparisons have not become been
transformed from the form uid1 == uid2 to user_namespace1 == user_namespace2 &&
uid1 == uid2.
Until that happens that user namespace remains incomplete and not very
useful. So the advice to users for now that unless they want to help
finish this up do not use.
Eric
Eric W. Biederman wrote:
> Michael Kerrisk <[email protected]> writes:
>
>> Hello Serge,
>>
>> In 2.6.23-rc, your patch to add support for CLONE_NEWUSER is included. Is
>> there there some for-userland-programmers documentation of this flag
>> somewhere? Would you be able to send some documentation to me (ideally as
>> a patch to the clone.2 man page, but otherwise some plain text will do).
>>
>> If this flag is also supported for unshare(), then could you please send me
>> a patch/text for that too?
>
> Currently this namespace is a work in progress marked with CONFIG_EXPERIMENTAL
> because it is very much still experimental and under development.
>
> There may be other omissions but the one I am most aware of is that
> the in kernel user and group equality comparisons have not become been
> transformed from the form uid1 == uid2 to user_namespace1 == user_namespace2 &&
> uid1 == uid2.
>
> Until that happens that user namespace remains incomplete and not very
> useful. So the advice to users for now that unless they want to help
> finish this up do not use.
And again: is CLONE_NEWUSER (to be)implemented for unshare()?
Thanks Eric. I'm still not so clear though. What is a user name space
intended to be, and how is it to be used?
Also, when will the implementation be complete? If not by the 2.6.23 final
release, it seems unfortunate to expose this flag to userspace, since
further down the road, it will be difficult for userspace to tell whether
the kernel below it really supports the flag or not. Or am I missing
something?
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.
Michael Kerrisk <[email protected]> writes:
>
> And again: is CLONE_NEWUSER (to be)implemented for unshare()?
They all should be. Only the pid namespace (not yet merged) looks
like a problem for unshare.
> Thanks Eric. I'm still not so clear though. What is a user name space
> intended to be, and how is it to be used?
>
> Also, when will the implementation be complete? If not by the 2.6.23 final
> release, it seems unfortunate to expose this flag to userspace, since
> further down the road, it will be difficult for userspace to tell whether
> the kernel below it really supports the flag or not. Or am I missing
> something?
Currently the code depends on CONFIG_USER_NS it is CONFIG_EXPERIMENTAL
and defaulting to N.
So no one should be shipping a production with it enabled, hopefully
that is enough, to avoid problems. I think the current implementation
is usable for some small subset of usable.
The basic idea is so that you have different mappings between uid and
gid values (i.e. /etc/passwd stuff) and struct user in the kernel.
Allowing the kernel to know two users with the same uid are distinct.
When you combined all of the namespaces (and when the are finished)
you have what is effective a chroot jail that looks like it has
the kernel all to itself despite other programs running.
Eric
Quoting Eric W. Biederman ([email protected]):
> Michael Kerrisk <[email protected]> writes:
>
> > Hello Serge,
> >
> > In 2.6.23-rc, your patch to add support for CLONE_NEWUSER is included. Is
> > there there some for-userland-programmers documentation of this flag
> > somewhere? Would you be able to send some documentation to me (ideally as
> > a patch to the clone.2 man page, but otherwise some plain text will do).
> >
> > If this flag is also supported for unshare(), then could you please send me
> > a patch/text for that too?
>
> Currently this namespace is a work in progress marked with CONFIG_EXPERIMENTAL
> because it is very much still experimental and under development.
>
> There may be other omissions but the one I am most aware of is that
> the in kernel user and group equality comparisons have not become been
> transformed from the form uid1 == uid2 to user_namespace1 == user_namespace2 &&
> uid1 == uid2.
I think the two main omissions are that one, and the fact that there is
no concept of a capability mask or per-namespace/cross-namespace
capabilities. What is implemented is separate accounting for the same
uid in different namespaces.
Until the shortcomings are addressed, depending on one's use case, one
may want to use selinux to control access across user namespaces.
> Until that happens that user namespace remains incomplete and not very
> useful. So the advice to users for now that unless they want to help
> finish this up do not use.
thanks,
-serge