RFE: add '--userns=...' option to 'pod create' command #7706

ensc · 2020-09-21T12:08:41Z

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Please add the '--userns=xxx' option to podman pod create so that it is possible to create (fully working) containers within a pod.

E.g. atm (podman-2.0.6-1.fc32.x86_64) it is not possible to do

podman pod create --name userns-test
podman run --pod=userns-test --user=root --rm -it --userns=keep-id busybox nc -l -p 22

(--> fails with "bind: Permission denied") while the same for a single container works:

podman run                   --user=root --rm -it --userns=keep-id busybox nc -l -p 22

[see https://github.com//issues/3993 too]

The text was updated successfully, but these errors were encountered:

mlezajic · 2020-09-25T09:05:15Z

Is there any chance to get this adressed somewhere in the near future? We really need to be able to add containers to a pod while keeping the current user id. Using podman v1.9.3 (go1.13.4) on a RHEL v8.3.1-5 machine we ecounter this (as mentioned above):

podman run --userns=keep-id --pod dev-pod-1 -dit --name centos 0d120b6ccaa8

results in

Error: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"sysfs\\\" to rootfs \\\"/home/fwd/.local/share/containers/storage/overlay/ab48d245cd5b06ca1b46c80ed7f64b4d6a5c23be27a6d79ee8321e5d18b5337a/merged\\\" at \\\"/sys\\\" caused \\\"operation not permitted\\\"\"": OCI runtime permission denied error

rhatdan · 2020-10-05T18:38:15Z

This seems logical that we should associate the usernamespace with the pod and then any containers that get attached would be placed within that user namespace.

dominic-p · 2020-10-15T04:31:40Z

Is this a regression? I could swear I was able to use --userns=keep-id inside a pod recently, but now I'm running into the same permission error.

mheon · 2020-10-15T13:32:53Z

No - this has never worked.

fcabralpacheco · 2020-10-17T05:11:52Z

@dominic-p
@mheon
I've been using containers with "--userns=keep-id" inside pods for some time on Fedora (Silverblue), and it works. The infra container will not be running with "--userns" ("UsernsMode"), but that it's not a problem for some use cases (I think).

@ensc

podman pod create --name userns-test
podman run --pod=userns-test --user=root --rm -it --userns=keep-id busybox nc -l -p 22

This kinda works with root user (you are requesting it to run as root and on a privileged port) (and it is necessary to add the ports when creating the pod), the error you reported appears when run as normal user.

However, if you have a user with the same UID in the image (or use only the UID), you can use it with unprivileged user namespaces, for example:

the first way if on the host you have that:

$ id
uid = 1000 (yourusername)

on the image you need:

$ id
uid = 1000 (anyotherusername)

after that you can run like that:

$ podman pod create --name userns-test -p 2222
$ podman run --rm -it --pod=userns-test --user=anyotherusername --userns=keep-id image_with_anyotherusername nc -l -p 2222

the second way (which I prefer and works with most of the available dockerhub images) is like that (using the UID):

$ podman pod create --name userns-test -p 2222
$ podman run --pod=userns-test --user=$(id -u) --rm -it --userns=keep-id busybox nc -l -p 2222

@mlezajic
I switched from docker to podman because it ended all my problems with permission in development containers (the tools work as if they were on the host and the big mess remains inside the container).

However I get in the same situation as yours with userns+pods, in the CentOS (in my case is CentOS 7 with cgroups v1), it doesn't work, I didn't test it on CentOS 8, but looking your version I think I'll get to the same result.
I think the problem is elsewhere, I tested it with podman 1.8 (from Fedora (rpmbuild), the default is 1.6) and the result is the same.

ensc · 2020-10-19T10:02:24Z

@fcabralpacheco

However, if you have a user with the same UID in the image (or use only the UID), you can use it with unprivileged user namespaces, for example

Port 22 int the example has been chosen because the real world container has /usr/sbin/sshd as entrypoint.

fcabralpacheco · 2020-10-20T06:33:33Z

@ensc

Like I mentioned before

but that it's not a problem for some use cases (I think).

I don't know exactly what application you need to use low ports, I believe that you need to use some image maintained by third parties. So I'm going to answer a way that would solve a situation like this.

To use a low port inside the container you need to adjust sysctl value "net.ipv4.ip_unprivileged_port_start" in the pod network namespace (infra container) or create a pod without infra container (and adjust in each container).

Method 1:

Create a pod and adjust the net.ipv4.ip_unprivileged_port_start value (without --userns=keep-id)

podman pod create --name userns-test -p 0.0.0.0:2222:22

podman run --rm -it --pod=userns-test --sysctl net.ipv4.ip_unprivileged_port_start=0 busybox true

Add a container to the pod

podman run --rm -it --pod=userns-test --user=$(id -u) --userns=keep-id  busybox nc -l -p 22

Method 2 (before that, read about what the infra container does):

podman pod create --name userns-test --infra=false

podman run --rm -it --pod=userns-test --user=$(id -u) --userns=keep-id  -p 0.0.0.0:2222:22 --sysctl net.ipv4.ip_unprivileged_port_start=0 busybox nc -l -p 22

If you need to listen on a low port on the host, you need to adjust the sysctl value (net.ipv4.ip_unprivileged_port_start=0) on the host itself.

ensc · 2020-10-20T10:07:32Z

@fcabralpacheco these are just dirty hacks; I expect to be able to run sshd in a container without lowering its security (playing with net.ipv4.ip_unprivileged_port_start) and to communicate with other containers within the pod (so I need the infra conainer).

The commands in the issue description are just minimal examples to demonstrate the problem. I do not want workarounds for the examples but to make real world scenarios to work.

fcabralpacheco · 2020-10-20T23:48:41Z

@ensc

Like I said:

I don't know exactly what application you need to use low ports

If you only need local communication, just don't use port mapping.

About "net.ipv4.ip_unprivileged_port_start=0", it is necessary if you want to use the keep-id and a pod with default infra container, I think you can't be root in the container and pod (infra) namespaces in that way.

If you want to run a server in one container and access from another you may use one of the following ways:

Method 1:

Create a pod and adjust the net.ipv4.ip_unprivileged_port_start value (without --userns=keep-id)

podman pod create --name userns-test

podman run --rm -it --pod=userns-test --sysctl net.ipv4.ip_unprivileged_port_start=0 busybox true

Server:

podman run --rm -it --pod=userns-test --user=$(id -u) --userns=keep-id  busybox nc -l -p 22

Client:

podman run --rm -it --pod=userns-test --user=$(id -u) --userns=keep-id  busybox nc userns-test 22

Method 2 (without --userns=keep-id):

Create a pod

podman pod create --name nouserns-test

Server:

podman run --rm -it --pod=nouserns-test --user=root busybox nc -l -p 22

Client:

podman run --rm -it --pod=nouserns-test --user=root busybox nc nouserns-test 22

The keep-id is used to map an unprivileged UID to an unprivileged one. I don't see a point in using keep-id and running as root inside a rootless container (it's way worse than '--sysctl net.ipv4.ip_unprivileged_port_start=0').
Maybe there is an use case that I don't know of, setuid to user later on? maybe that is the case, is sshd, you don't need just a port, you will have more errors later on with an unprivileged user.
The method 1 with "--user=root" might work in that case.

fcabralpacheco · 2020-10-20T23:58:16Z

@mlezajic

I tested (on CentOS 8) with crun, cgroupsv2, and the error just changed. I think I'm doing something wrong on CentOS.

ensc · 2020-10-21T09:59:27Z

@fcabralpacheco

f you want to use the keep-id and a pod with default infra container, I think you can't be root in the container and pod (infra) namespaces in that way.

That is the subject of this issue: a request to add --userns= to the pod create command so that the infra container is created in that way.

I do not want support or workarounds for minimal examples which are demonstrating the issue.

github-actions · 2020-11-21T00:14:25Z