default gid map not allowed error when uid != gid

[dtrudg]

crun version 1.6
commit: 18cf2efbb8feb2b2f20e316520e0fd0b6c41ef4d
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL

At the following line...

crun/src/libcrun/linux.c

Line 2808 in bebd67f

gid_map_len = format_default_id_mapping (&gid_map, container->container_gid, container->host_uid, 0);

... the code creating a default gid mapping, when a mapping is not provided in the config.json, appears to be using container_gid to host_uid instead of container_gid to host_gid.

Edit - though I see this... a16fb8c so I'm probably not finding the whole picture here.

This often succeeds as in simple setups a user commonly has a primary group with a gid that is the same numerically as their uid. However when this is not the case:

$ id
uid=1001(circleci) gid=1002(circleci)

...and the config.json requests this gid...

	"process": {
		"terminal": true,
		"user": {
			"uid": 1001,
			"gid": 1002
		},
		...

... then execution will fail, because the mapping is incorrect...

$ crun --debug --root /run/user/1001/singularity-oci run -b /tmp/oci-bundle904459226 24a57941-dd9e-405d-85d3-0e56c17adf72
2022-11-18T15:56:09.000296196Z: non root user need to have an 'user' namespace
newgidmap: gid range [1002-1003) -> [1001-1002) not allowed
2022-11-18T15:56:09.000297587Z: unable to invoke newgidmap, will try creating a user namespace with single mapping as an alternative
2022-11-18T15:56:09.000299080Z: setresgid to 0: Invalid argument

[giuseppe]

I'll try to reproduce here. This code path is not very well tested because usually crun runs already in a user namespace.
Could you please share the content of /etc/subuid and /etc/subgid?

[dtrudg]

I'll try to reproduce here. This code path is not very well tested because usually crun runs already in a user namespace. Could you please share the content of /etc/subuid and /etc/subgid?

Understood. It's not something that really affects us a great deal. Calling from outside a userns, and without providing uid/gid mappings is just a bit of a stepping stone in something I've been working up... not something that we'll really be doing long term, but I thought I'd report the issue.

The situation arises on a CircleCI instance with id mapping files as below:

circleci@ip-172-28-22-174:~$ cat /etc/subuid
ubuntu:100000:65536
circleci:165536:65536

circleci@ip-172-28-22-174:~$ cat /etc/subgid
ubuntu:100000:65536
circleci:165536:65536

circleci@ip-172-28-22-174:~$ id
uid=1001(circleci) gid=1002(circleci) groups=1002(circleci),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),118(netdev),119(lxd),997(docker),1000(ubuntu),1001(aws-sudoers)

Thanks!

[giuseppe]

thanks for the extra information, opened a PR here: #1073