[CRIU] [PATCH 1/4] Support for dumping/restoring user namespaces

[Aditya Kali]

On Wed, Aug 13, 2014 at 12:53 AM, Cyrill Gorcunov <gorcunov at gmail.com> wrote:
> On Mon, Aug 11, 2014 at 05:17:10PM +0400, Andrew Vagin wrote:
>> Hi Sophie,
>>
>> On Fri, Aug 08, 2014 at 10:21:19PM -0700, Sophie Blee-Goldman wrote:
>> > Adds basic support for user namespaces by dumping and restoring
>> > the namespace itself and the uid/gid maps of the root process.
>>
>> How do you test your patches? ZDTM test suite can execute tests in
>> namespaces, but the current version knows nothing about userns. Have you
>> try to add userns in ZDTM lib?
>>
>> >
>> > Currently depends on a kernel patch to avoid failing on the prctl
>> > syscall by checking for CAP_SYS_RESOURCE in the user namespace
>> > instead of in the global one.
>>
>> It isn't so simple.
>> Kirill is trying to fix this issue: https://lkml.org/lkml/2014/8/4/570
>
> Yes, this particular series is acked by Serge but didn't reach -mm
> or -next tree yet, I think people need more time to think if it is
> safe.
>
>>
>> We have a number of other kernel issues, which are described here:
>> http://criu.org/UserNamespace
>>
>> Have you seen my patches for userns?
>> http://lists.openvz.org/pipermail/criu/2014-February/012399.html
>>
>> and here is updated version:
>> https://github.com/avagin/criu/tree/userns2
>>
>> I suggest to find the difference between our patch sets and make a new one,
>> which will contain best things from both ones.

Some of Sophie's changes/fixes are applicable to main criu branch even
without userns support. Other userns specific changes could be applied
to the Andrew Vagin's userns tree. They will need to be split
accordingly.

>
> Guys, actually I don't see much point in implementing user-ns support until
> all restrictions from kernel are moved off. I mean we can prepare kind of
> scaffold code (I must admit I didn't read the series precisely) but without
> kernel support it might be a waste of time, the kernel interface variant
> which will be eventually merged might be completely different from initial
> proposal. Thus, from my POV -- priority number 1 is to address the kernel.
>
> Still, if we need a scaffold code -- it should be quite "common" and won't
> require much efforts to change once kernel get stabilized in new interfaces.
>
> Don't get me wrong please, I'm not against user-ns development in criu at
> the current stage but it must be done by very small pieces keeping in mind
> that kernel migh be heavily changed.

Even with kernel changes not finalized, I find it useful to have
userns changes in CRIU done somewhere. With Sophie's patches, the
CRIU-userns support atleast lets us dump and restore uid mappings &
capabilities (with experimental kernel). I feel its valuable to be
able to test these as it lets us find issues in our container setup
early on.

Thanks,
-- 
Aditya