Re: Capabilities are list when creating a user namespace

From: Idan Yadgar
Date: Thu Jun 04 2020 - 01:59:08 EST

Hello, sorry for duplicating the previous email, forgot to send it to
the mailing lists as well.
Did you miss my email?

Idan Yadgar.

On Fri, May 29, 2020 at 5:48 PM Idan Yadgar <idanyadgar@xxxxxxxxx> wrote:
> Hello, did you miss my mail?
> ×××××× ××× ××, 24 ×××× 2020, 15:32, ××× Idan Yadgar â<idanyadgar@xxxxxxxxx>:
>> Hello,
>> A process which changes its user namespace (unshare or setns), or a
>> process that is created by clone with the CLONE_NEWUSER flag has all
>> capabilities inside the new namespace, and loses all its capabilities
>> in the parent/previous user namespace.
>> This poses an issue because some operations require a capability in a
>> user namespace other then the current one for the process. The man
>> states multiple times that a system call requires a capability in the
>> initial user namespace (for example, open_by_handle_at requires
>> CAP_DAC_READ_SEARCH in the initial user namespace), but this cannot
>> happen unless the process is owned by root, thus preventing
>> open_by_handle_at to be run inside a user namespace.
>> Solving this problem can be done by allowing (via prctl or any other
>> mechanism) a task to save its
>> capabilities for a given user namespace, even when it isn't a member
>> in that namespace.
>> We would like to hear some thoughts about this issue and our proposed solution.