Current state of CLONE_NEWUSER?

Current state of CLONE_NEWUSER?

[Michael Kerrisk]

Hi Serge,

What is the current status of CLONE_NEWUSER?  I'm currently trying to
test this flag in preparation for documenting it in the clone(2) man
page, but am running into an ENOMEM error from the clone() call, which
seems to occur after a failure in kobject_init_and_add() in the
following call sequence:

clone_user_ns() --> alloc_uid() --> uids_user_create() -->
kobject_init_and_add()

Are there already some test programs somewhere?  Is there any
documentation already available for this flag?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: Current state of CLONE_NEWUSER?

[Eric W. Biederman]

"Michael Kerrisk" <mtk.manpages@googlemail.com> writes:

> Hi Serge,
>
> What is the current status of CLONE_NEWUSER?  I'm currently trying to
> test this flag in preparation for documenting it in the clone(2) man
> page, but am running into an ENOMEM error from the clone() call, which
> seems to occur after a failure in kobject_init_and_add() in the
> following call sequence:
>
> clone_user_ns() --> alloc_uid() --> uids_user_create() -->
> kobject_init_and_add()
>
> Are there already some test programs somewhere?  Is there any
> documentation already available for this flag?

This code is definitely still under development.

When complete it should be able to create a new uid namespace,
as an unprivileged user.  Creating a new process with uid == gid == 0.
Have a full set of caps.  And have permission to do nothing on the system
except read world readable files and write world writable files.

Eric

Re: Current state of CLONE_NEWUSER?

[Michael Kerrisk]

Hi Eric,

On Wed, Nov 19, 2008 at 8:41 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> "Michael Kerrisk" <mtk.manpages@googlemail.com> writes:
>
>> Hi Serge,
>>
>> What is the current status of CLONE_NEWUSER?  I'm currently trying to
>> test this flag in preparation for documenting it in the clone(2) man
>> page, but am running into an ENOMEM error from the clone() call, which
>> seems to occur after a failure in kobject_init_and_add() in the
>> following call sequence:
>>
>> clone_user_ns() --> alloc_uid() --> uids_user_create() -->
>> kobject_init_and_add()
>>
>> Are there already some test programs somewhere?  Is there any
>> documentation already available for this flag?
>
> This code is definitely still under development.
>
> When complete it should be able to create a new uid namespace,
> as an unprivileged user.  Creating a new process with uid == gid == 0.
> Have a full set of caps.  And have permission to do nothing on the system
> except read world readable files and write world writable files.

Thanks for the info,

So the error I described is expected?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: Current state of CLONE_NEWUSER?

[Eric W. Biederman]

"Michael Kerrisk" <mtk.manpages@googlemail.com> writes:

> Hi Eric,
>
> On Wed, Nov 19, 2008 at 8:41 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk" <mtk.manpages@googlemail.com> writes:
>>
>>> Hi Serge,
>>>
>>> What is the current status of CLONE_NEWUSER?  I'm currently trying to
>>> test this flag in preparation for documenting it in the clone(2) man
>>> page, but am running into an ENOMEM error from the clone() call, which
>>> seems to occur after a failure in kobject_init_and_add() in the
>>> following call sequence:
>>>
>>> clone_user_ns() --> alloc_uid() --> uids_user_create() -->
>>> kobject_init_and_add()
>>>
>>> Are there already some test programs somewhere?  Is there any
>>> documentation already available for this flag?
>>
>> This code is definitely still under development.
>>
>> When complete it should be able to create a new uid namespace,
>> as an unprivileged user.  Creating a new process with uid == gid == 0.
>> Have a full set of caps.  And have permission to do nothing on the system
>> except read world readable files and write world writable files.
>
> Thanks for the info,
>
> So the error I described is expected?

I don't think so.  Serge?

Eric

Re: Current state of CLONE_NEWUSER?

[Serge E. Hallyn]

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Michael Kerrisk" <mtk.manpages@googlemail.com> writes:
> 
> > Hi Eric,
> >
> > On Wed, Nov 19, 2008 at 8:41 PM, Eric W. Biederman
> > <ebiederm@xmission.com> wrote:
> >> "Michael Kerrisk" <mtk.manpages@googlemail.com> writes:
> >>
> >>> Hi Serge,
> >>>
> >>> What is the current status of CLONE_NEWUSER?  I'm currently trying to
> >>> test this flag in preparation for documenting it in the clone(2) man
> >>> page, but am running into an ENOMEM error from the clone() call, which
> >>> seems to occur after a failure in kobject_init_and_add() in the
> >>> following call sequence:
> >>>
> >>> clone_user_ns() --> alloc_uid() --> uids_user_create() -->
> >>> kobject_init_and_add()
> >>>
> >>> Are there already some test programs somewhere?  Is there any
> >>> documentation already available for this flag?
> >>
> >> This code is definitely still under development.
> >>
> >> When complete it should be able to create a new uid namespace,
> >> as an unprivileged user.  Creating a new process with uid == gid == 0.
> >> Have a full set of caps.  And have permission to do nothing on the system
> >> except read world readable files and write world writable files.
> >
> > Thanks for the info,
> >
> > So the error I described is expected?
> 
> I don't think so.  Serge?

I suspect you have the fair scheduler compiled in
(CONFIG_FAIR_GROUP_SCHED).  So when you create a new user namespace, it
tries to create a new /sys/kernel/uids/0 (or thereabouts) directory
which sysfs refuses.

The fix for this was rolled in as the last patch in the rejected large
network namespace/sysfs rework.  So we'll need another fix.  I suspect
following the same path as we did for making network namespaces work is
the best path for now.  (This being my last day of a week-long vacation
I won't be sending a patch today :)

-serge

Re: Current state of CLONE_NEWUSER?

[Michael Kerrisk]

Hi Serge,

On Fri, Nov 21, 2008 at 10:07 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> "Michael Kerrisk" <mtk.manpages@googlemail.com> writes:
>>
>> > Hi Eric,
>> >
>> > On Wed, Nov 19, 2008 at 8:41 PM, Eric W. Biederman
>> > <ebiederm@xmission.com> wrote:
>> >> "Michael Kerrisk" <mtk.manpages@googlemail.com> writes:
>> >>
>> >>> Hi Serge,
>> >>>
>> >>> What is the current status of CLONE_NEWUSER?  I'm currently trying to
>> >>> test this flag in preparation for documenting it in the clone(2) man
>> >>> page, but am running into an ENOMEM error from the clone() call, which
>> >>> seems to occur after a failure in kobject_init_and_add() in the
>> >>> following call sequence:
>> >>>
>> >>> clone_user_ns() --> alloc_uid() --> uids_user_create() -->
>> >>> kobject_init_and_add()
>> >>>
>> >>> Are there already some test programs somewhere?  Is there any
>> >>> documentation already available for this flag?
>> >>
>> >> This code is definitely still under development.
>> >>
>> >> When complete it should be able to create a new uid namespace,
>> >> as an unprivileged user.  Creating a new process with uid == gid == 0.
>> >> Have a full set of caps.  And have permission to do nothing on the system
>> >> except read world readable files and write world writable files.
>> >
>> > Thanks for the info,
>> >
>> > So the error I described is expected?
>>
>> I don't think so.  Serge?
>
> I suspect you have the fair scheduler compiled in
> (CONFIG_FAIR_GROUP_SCHED).

True.

> So when you create a new user namespace, it
> tries to create a new /sys/kernel/uids/0 (or thereabouts) directory
> which sysfs refuses.

Okay.

> The fix for this was rolled in as the last patch in the rejected large
> network namespace/sysfs rework.  So we'll need another fix.  I suspect
> following the same path as we did for making network namespaces work is
> the best path for now.  (This being my last day of a week-long vacation
> I won't be sending a patch today :)

Yep, I saw your patch, thanks.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html