`newgidmap` with only own gid, blocks `nsenter`

[eZioPan]

Let's assume user_a has GID 1000, and an entry in /etc/subgid user_a:10000:100.

When user run following commands:

unshare --user -- catatonit -P &
newuidmap <PID> 0 1000 1
newgidmap <PID> 0 1000 1
nsenter --target <PID> --user

nsenter will return nsenter: setgroups failed: Operation not permitted, since /proc/<PID>/setgroups has been set to deny.

But if user add an extra gid map, then nsenter works:

unshare --user -- catatonit -P &
newuidmap <PID> 0 1000 1
# add a range within /etc/subgid
newgidmap <PID> 0 1000 1 1 10000 10
nsenter --target <PID> --user

I don't get it logically why add an extra gid map should make /proc/<PID>/setgroups becomes allow. And this further affect nsenter's behavior.

I find this code leaves *allow_setgroups unmodified and makes setgroups to deny.

shadow/src/newgidmap.c

Lines 41 to 45 in ea109a3

	/* Allow a process to map its own gid. */
	if ((range->count == 1) && (getgid() == range->lower)) {
	/* noop -- if setgroups is enabled already we won't disable it. */
	return true;
	}

Is this behavior intentional (set own gid map only cause setgroups to deny)? Or could this a bug from nsenter(require a setgroups to work)?

[hallyn]

Yeah, if you look at the comments,

 85         /*
 86          * Default is "deny", and any "allow" will out-rank a "deny". We don't
 87          * forcefully write an "allow" here because the process we are writing
 88          * mappings for may have already set themselves to "deny" (and "allow"
 89          * is the default anyway). So allow_setgroups == true is a noop.
 90          */

it was in fact the intent for deny to be the default.

I would be happy to accept a patch adding a '--allow-setgroups' option to newgidmap.

[hallyn]

Oh, actually, no, we can't take such a patch. Here's why: if some site is actually using negative group acls to prevent some users from reading certain files, then allowing newgidmap to bypass that means we are letting the unprivileged untrusted user bypass admin-imposed restrictions. In contrast, if the admin has given the user subuids, then we can assume that it was intentional, and setgroups is ok.

So, we could add the option, but it would have to be refused if the user does not have any /etc/subgid entries.

[eZioPan]

Hi, thank you for your detailed explanation! So I guess it might not be a good idea to change newgidmap, since it might introduce security vulnerabilities? If you think this is not worth the risk, please close this issue, thanks.

[hallyn]

On Sat, Jun 07, 2025 at 08:55:58PM -0700, eZio Pan wrote: Hi, thank you for your detailed explanation! So I guess it might not be a good idea to change `newgidmap`, since it might introduce security vulnerabilities? If you think this is not worth the risk, please close this issue, thanks.

I personally think that it would be ok so long as we make sure that both 1. a new flag is required (so that default behavior does not change) and 2. it can only be done by users who have subgids specified (so that the admin has bought into it) Since users with a subgid can just add their assigned subgids to the map and achieve the same thing, we're not loosening any requirements in that case. So I'm ok leaving this open, if someone wants to write a PR for it. I'd prefer if we didn't need 1, as it's an inconsistency... So in fact, I'd be ok even with a PR that does (2) and then adds a clear message to the Changelog saying that this is a possibly breaking change. I don't believe anyone is *counting* on that behavior. Just can't prove it.