Messages in this thread | | | Date | Fri, 21 Nov 2008 09:07:10 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: Current state of CLONE_NEWUSER? |
| |
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
| |