Comment 11 for bug 1729357

> Thanks for replying Eric, but I'm having trouble reproducing what you've
> posted. I can't write the gid map until I've written deny to
> /prod/$pid/setgroups, not the other way around. There might be some nuance
> I've missed.

Yes, this is a security feature. setgroups must be written to *before* gid_map
(the reason for this is explained further in user_namespaces(7)). And only
privileged users are allowed to write to gid_map if setgroups is set to allow.

> Also, newgidmap will allow a user to map their own GID to 0 in the user
> namespace, even when there is no entry for that user in /etc/subgid.

This is something that is generally required for a container to function, and
isn't fundamentally a security issue because users are already allowed to do
that without privileges (this is how rootless containers and LXC unprivileged
containers work) -- *unless* in this mode newgidmap is setting setgroups=allow
(in which case this is a major security problem).

> What if newgidmap wrote "deny" to /proc/$pid/setgroups unless the user is
> whitelisted in some config file, probably separate from /etc/subgid, as
> Stéphane suggested?

:+1: I'd prefer if we implemented this by changing the /etc/subgid schema so
that rather than having the format

   user:id:id_cnt

It has the format

   user:id:id_cnt[:flagA,flagB,...]

And we define flags "allow_setgroups" and "deny_setgrouops" (with
"deny_setgroups" being the default). This way, administrators can be *explicit*
about the denial, we don't add any new configuration files, and it's backwards
compatible (with security being opt-out).

I imagine making deny_setgroups might be a *bit* contentious, but in the worst
case we could have a migration script that asks users (or just add a document
about it to the logfile for the upgrade).