runc in container with regular user

[rclUPC]

Hi,
I am trying to use a simulation tool, DAFoam (https://dafoam.github.io/), in a cluster managed with SLURM. DAFoam can be downloaded as a docker image for simplicity, but docker is not supported by SLURm at least the version installed, 21.08 (https://slurm.schedmd.com/archive/slurm-21.08.5/containers.html). It supports, however, OCI Runtime.
I exported the docker image to a OCI folder, and I managed to make it work with sudo. When I try to run it without sudo I get a permission error:

$ runc --rootless=true run dafoam1
FATA[0000] nsexec-0[76730]: failed to use newuid map on 76733: Operation not permitted 
FATA[0000] nsexec-1[76733]: failed to sync with parent: read(SYNC_USERMAP_ACK): Success 
ERRO[0000] runc run failed: unable to start container process: can't get final child's PID from pipe: EOF 

The config.json file is this one:

{
	"ociVersion": "1.0.0",
	"process": {
		"terminal": true,
		"user": {
			"uid": 1000,
			"gid": 1000
		},
		"args": [
			"bash"
		],
		"env": [
			"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
			"TERM=xterm",
			"HOME=/root"
		],
		"cwd": "/",
		"capabilities": {
			"bounding": [
				"CAP_AUDIT_WRITE",
				"CAP_KILL",
				"CAP_NET_BIND_SERVICE"
			],
			"effective": [
				"CAP_AUDIT_WRITE",
				"CAP_KILL",
				"CAP_NET_BIND_SERVICE"
			],
			"inheritable": [
				"CAP_AUDIT_WRITE",
				"CAP_KILL",
				"CAP_NET_BIND_SERVICE"
			],
			"permitted": [
				"CAP_AUDIT_WRITE",
				"CAP_KILL",
				"CAP_NET_BIND_SERVICE"
			],
			"ambient": [
				"CAP_AUDIT_WRITE",
				"CAP_KILL",
				"CAP_NET_BIND_SERVICE"
			]
		},
		"rlimits": [
			{
				"type": "RLIMIT_NOFILE",
				"hard": 1024,
				"soft": 1024
			}
		],
		"noNewPrivileges": true
	},
	"root": {
		"path": "rootfs"
	},
	"hostname": "umoci-default",
	"mounts": [
		{
			"destination": "/proc",
			"type": "proc",
			"source": "proc"
		},
		{
			"destination": "/dev",
			"type": "tmpfs",
			"source": "tmpfs",
			"options": [
				"nosuid",
				"strictatime",
				"mode=755",
				"size=65536k"
			]
		},
		{
			"destination": "/dev/pts",
			"type": "devpts",
			"source": "devpts",
			"options": [
				"nosuid",
				"noexec",
				"newinstance",
				"ptmxmode=0666",
				"mode=0620"
			]
		},
		{
			"destination": "/dev/shm",
			"type": "tmpfs",
			"source": "shm",
			"options": [
				"nosuid",
				"noexec",
				"nodev",
				"mode=1777",
				"size=65536k"
			]
		},
		{
			"destination": "/dev/mqueue",
			"type": "mqueue",
			"source": "mqueue",
			"options": [
				"nosuid",
				"noexec",
				"nodev"
			]
		},
		{
			"destination": "/sys",
			"type": "bind",
			"source": "/sys",
			"options": [
				"rbind",
				"nosuid",
				"noexec",
				"nodev",
				"ro"
			]
		},
		{
			"destination": "/etc/resolv.conf",
			"type": "bind",
			"source": "/etc/resolv.conf",
			"options": [
				"nodev",
				"noexec",
				"nosuid",
				"rbind",
				"ro"
			]
		}
	],
	"annotations": {
		"org.opencontainers.image.architecture": "amd64",
		"org.opencontainers.image.author": "",
		"org.opencontainers.image.created": "2023-09-24T19:30:12.299250603Z",
		"org.opencontainers.image.exposedPorts": "",
		"org.opencontainers.image.os": "linux",
		"org.opencontainers.image.stopSignal": ""
	},
	"linux": {
		"uidMappings": [
			{
				"containerID": 0,
				"hostID": 1000,
				"size": 32000
			}
		],
		"gidMappings": [
			{
				"containerID": 0,
				"hostID": 1000,
				"size": 32000
			}
		],
		"namespaces": [
			{
				"type": "pid"
			},
			{
				"type": "ipc"
			},
			{
				"type": "uts"
			},
			{
				"type": "mount"
			},
			{
				"type": "user"
			}
		],
		"maskedPaths": [
			"/proc/kcore",
			"/proc/latency_stats",
			"/proc/timer_list",
			"/proc/timer_stats",
			"/proc/sched_debug",
			"/sys/firmware",
			"/proc/scsi"
		],
		"readonlyPaths": [
			"/proc/asound",
			"/proc/bus",
			"/proc/fs",
			"/proc/irq",
			"/proc/sys",
			"/proc/sysrq-trigger"
		]
	}
}

I want to enter the container as the user 1000, not root. Even entering wth sudo, I get the user correctly, but $HOME is still defined as /root.
Summarizing, I would like to execute this OCI container with the same options defined by DAFoam developer for docker:

docker run -it --rm -u dafoamuser --mount "type=bind,src=$(pwd),target=/home/dafoamuser/mount" -w /home/dafoamuser/mount dafoam/opt-packages:v3.0.7 bash

but I don't know how to modify the config.json file in order to get this.

Regards

Robert

[lifubang]

You can see the ‘config.json’ in the docker, maybe you can find it in ‘/run/containerd’ with container’s id.

[rclUPC]

Thanks for the replay. It seems a good solution, but I am not able to find this config.json file in the whole system. The /run/containerd' folder is this one:

srw-rw---- 1 root root  0 Oct 15 10:48 containerd.sock
srw-rw---- 1 root root  0 Oct 15 10:48 containerd.sock.ttrpc
drwx--x--x 2 root root 40 Oct 15 10:48 io.containerd.runtime.v1.linux
drwx--x--x 2 root root 40 Oct 15 10:48 io.containerd.runtime.v2.task

It doesn't seem to contain any container.

According to docker inspect, the container should be in '/var/lib/docker/containers'

       "Id": "17dca97d717ac20d8ac17cc1f28bf1adafcf0ef2879d0c8ed438248595332ad1"

but there is no folder with the containers id name in this place

drwx--x--- 4 root root 4096 Oct 15 10:48 3001676de0d2d3cde42510a24f9f92685d93032c4681cebb87797efe9a483955
drwx--x--- 4 root root 4096 Oct 15 10:48 347385bb7df4ef573f39f04f58afb8a0f644ebdcd1ae92d44e7076d183ecef2d
drwx--x--- 4 root root 4096 Oct 15 10:48 8c9b44f9ab4cc140b8c572b63fc05134ecb016edef7896581cc01c33354edd88
drwx--x--- 3 root root 4096 Oct 15 10:48 960a95e3dc10c76819b8ccbc89f0a8d340d4ea5b1b8b563fa26679a1570c2ecc
drwx--x--- 4 root root 4096 Oct 15 10:48 ca1c5437f6a44235882d2e715f03b8824bcda02879efa1acbf3c8058bfacbe70
drwx--x--- 4 root root 4096 Oct 15 10:48 f20ad8047c9a7376de4d6420caf7f60533e39d84d2bfb2a76003fa3dd9b15dcb

[lifubang]

If you use old version of docker & containerd, it will be in io.containerd.runtime.v1.linux, or else it will be in io.containerd.runtime.v2.task. For example, I use an newer version of docker & containerd:

root@acmcoder:/home/acmcoder# docker ps | grep test
3a894cc81b32   golang                             "/bin/bash"              6 days ago      Up 4 minutes                                                          test
root@acmcoder:/home/acmcoder# find /run/containerd/ -name "3a894cc81b32*"
/run/containerd/io.containerd.runtime.v2.task/moby/3a894cc81b32f80d7eeff049653c998491a0037af6c3c8d548331da5c2839fa6
root@acmcoder:/home/acmcoder# ls /run/containerd/io.containerd.runtime.v2.task/moby/3a894cc81b32f80d7eeff049653c998491a0037af6c3c8d548331da5c2839fa6
address  config.json  init.pid  log  log.json  options.json  rootfs  runtime  shim-binary-path  work

In this example, the config.json is in the path: /run/containerd/io.containerd.runtime.v2.task/moby/3a894cc81b32f80d7eeff049653c998491a0037af6c3c8d548331da5c2839fa6

[rclUPC]

Thank you, @lifubang. I managed to make it work with your indications, but nly as root (with sudo). I don't know how to configure it as rootless.
I have followed the indications given by slurm, with no success. The harder part is the uid and gid mapping. Honestly, I dont kow how it works, and what are the roles of /etc/subuid and /etc/subgid.
If I setup the config.json, as suggested by SLURM, with

 "linux": {
                "uidMappings": [
                       {
                               "containerID": 0,
                               "hostID": 1000,
                               "size": 1
                       }
               ],
               "gidMappings": [
                       {
                               "containerID": 0,
                               "hostID": 1000,
                               "size": 1
                       }
               ],

I get the error:
ERRO[0000] runc run failed: unable to start container process: unable to setup user: cannot set uid to unmapped user in user namespace

[codethief]

@rclUPC Did you set up /etc/subuid and /etc/subgid as described e.g. on https://rootlesscontaine.rs/getting-started/common/subuid/ ? The two files basically describe which UIDs / GIDs on your host machine are "available" to your host machine user account that you're using to start runc. Here, "available" = "can be used to run a container process." In other words: subuid/subgid are about permissions. The actual mapping between UID/GIDs inside the container to the aforementioned UID/GIDs outside the container is described in the uidMappings/gidMappings part of config.json that you posted. See also man newuidmap and man newgidmap.

[cyphar]

This error:

FATA[0000] nsexec-0[76730]: failed to use newuid map on 76733: Operation not permitted

is because runc doesn't have permissions to get the requested mappings. If you have privileges to edit /etc/subuid and /etc/subgid you can give runc access to the mappings you need. See man newuidmap and man newgidmap for more information (you can use usermod to add the mappings if you prefer this to modifying /etc/subuid and /etc/subgid directly).

In addition, the mapping in your original comment (0:1000:32000) is not exactly recommended because it will cause your container's uids to overlap with host users, which can lead to possible security issues.

If you don't have admin privileges on the machine, then your best bet is to let the container user be root inside the container. Linux only allows unprivileged user namespaces to map a single uid and gid (newuidmap and newgidmap are setuid helpers that give you the ability to map more users) so you need to do something like this:

	"process": {
		"user": {
			"uid": 0,
			"gid": 0
		}
	}
	...
	"linux": {
                "uidMappings": [
                       {
                               "containerID": 0,
                               "hostID": 1000,
                               "size": 1
                       }
               ],
               "gidMappings": [
                       {
                               "containerID": 0,
                               "hostID": 1000,
                               "size": 1
                       }
               ]
	}

Linux also lets you map only your own user, but I suspect this won't work:

	"process": {
		"user": {
			"uid": 1000,
			"gid": 1000
		}
	}
	...
	"linux": {
                "uidMappings": [
                       {
                               "containerID": 1000,
                               "hostID": 1000,
                               "size": 1
                       }
               ],
               "gidMappings": [
                       {
                               "containerID": 1000,
                               "hostID": 1000,
                               "size": 1
                       }
               ]
	}