Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Michael Kerrisk" <mtk.manpages@xxxxxxxxxxxxxx> writes: > > > Hi Eric, > > > > On Wed, Nov 19, 2008 at 8:41 PM, Eric W. Biederman > > <ebiederm@xxxxxxxxxxxx> wrote: > >> "Michael Kerrisk" <mtk.manpages@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
