Aleksa Sarai

> But maybe this will cause the issues like runc-dmz if we use execve in stage-2? We still have full capabilities at the beginning of stage-2 (both with and without...

This patch also works, while still allowing us to use `CLONE_PARENT`. Yes, I'm sure we agree it's not lovely, but IMHO using `fork()` is depending on glibc internals just as...

I was about to write a similar PR 😅. I'll close this once I send that one. I'll also be on PTO from next week.

Since `RUNC_DMZ` is now opt-in, IMHO we can remove the logic in `libcontainer/dmz/selinux*.go`. We must keep `isDmzBinarySafe` because we don't want an environment variable to make containers unsafe, but the...

That particular example is a configuration error -- if you join an existing namespace (such as IPC) and then make a new user namespace you won't have any capabilities over...

@lifubang That's just how user namespaces work. Every other namespace instance is owned by a user namespace, and capability permissions are based on the owning user namespace (**not** the kuid...

> Maybe along those lines though a fix could be opting out of runc-dmz if there are any capabilities in the bounding set which aren't in the inheritable and ambient...

@dgl > or even look at the file capabilities of the binary being run, although that is potentially racy This would be fundamentally unsafe to do, due to the obvious...

Luckily, in runc we only accept uid and gids, as opposed to usernames†. So we could _in principle_ just check if the `config.json` uid is 0 but it might require...

We can make it so that `RUNC_DMZ` is used to opt-in to the feature. I'll send a PR once I finish with the cleanups of #3985.