Messages in this thread | | | From | Idan Yadgar <> | Date | Thu, 4 Jun 2020 08:58:08 +0300 | Subject | Re: Capabilities are list when creating a user namespace |
| |
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@gmail.com> wrote: > > Hello, did you miss my mail? > > בתאריך יום א׳, 24 במאי 2020, 15:32, מאת Idan Yadgar <idanyadgar@gmail.com>: >> >> 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.
| |