> Yes, obviously mknod is capability checked in the kernel, as there is a capability with that very name.
Yes, and it's checked against the root user namespace, not your current one. Which means that it's not as simple as "do I have this capability". It's "do I have this capability in this user namespace". Which is what I said originally, so I'm not sure what you're debating here.
> My point was that in your talk and comments you make some suggestions which I feel are misleading or inaccurate. In some cases this is probably because you are discussing your own implementation.
Can you give some examples? If I'm wrong about something, I'd love to see an example of it so I can correct it in the future. In particular, I'd like to know what parts of my discussion are related to runC's implementation of containers.
> capabilities are not 'part of' namespaces, any more than block devices are 'part of' the filesystem
Capabilities are effectively 4 bitmasks that are scoped to user namespaces. Yes, they aren't technically part of "struct user_namespace_t" but the way they are used make them quite intricately related. Much more intricately related than block device inodes in a filesystem.
> given that most security checks occur in other kernel subsystems, and a holistic conception is implied by the word 'unpriveleged'.
But those security checks generally will use either ns_capable (so they're all hooked up to the user namespace scoping logic), basic UID/GID checks (which are also hooked up to user namespace mapping logic) or some other security framework that is effectively an additional ACL (and isn't the purview of namespaces anyway).
The main complaint I would understand from the use of "unprivileged namespace" is that the kernel doesn't actually mark namespaces as being privileged or unprivileged, it just so happens that unprivileged namespaces act slightly differently because of how they are set up. But AFAICS that's not the argument you're making.