On Fri, Nov 10, 2017 at 1:30 PM, Serge E. Hallyn [off-list ref] wrote:

Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
...

quoted

quoted

quoted

 ==============================================================

+controlled_userns_caps_whitelist
+
+Capability mask that is whitelisted for "controlled" user namespaces.
+Any capability that is missing from this mask will not be allowed to
+any process that is attached to a controlled-userns. e.g. if CAP_NET_RAW
+is not part of this mask, then processes running inside any controlled
+userns's will not be allowed to perform action that needs CAP_NET_RAW
+capability. However, processes that are attached to a parent user-ns
+hierarchy that is *not* controlled and has CAP_NET_RAW can continue
+performing those actions. User-namespaces are marked "controlled" at
+the time of their creation based on the capabilities of the creator.
+A process that does not have CAP_SYS_ADMIN will create user-namespaces
+that are controlled.

Hm.  I think that's fine (the way 'controlled' user namespaces are
defined), but that is design decision in itself, and should perhaps be
discussed.

Did you consider other ways?  What about using CAP_SETPCAP?

I did try other ways e.g. using another bounding-set etc. but
eventually settled with this approach because of main two properties -

No, I meant did you try other ways of defining a controlled user
namespace, other than one which is created by a task lacking
CAP_SYS_ADMIN?

SYS_ADMIN is the capability that has been used for deciding who can or
cannot create namespaces, so didn't want to create another model that
may not be compatible with current model which is well understood
hence no.

...

quoted

quoted

quoted

+The value is expressed as two comma separated hex words (u32). This

Why comma separated?  whitespace ok?  Leading 0x ok?  What is the
default at boot?  (Obviously the patch tells me, I'm asking for it
to be spelled out in the doc)

I tried multiple ways including representing capabilities in
string/name form for better readability but didn't want to add
additional complexities of dealing with strings and possible
string-related-issues for this. Also didn't want to reinvent the new
form so settled with something that is widely used (cpu
bounding/affinity/irq mapping etc.) and is capable of handling growing
bit set (currently 37 but possibly more later).

Ok, thanks.