add configuration option for disabling new keyring

[gzm55]

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

/kind feature

Description

In a rootless container with lean capabilities, to create a container by podman run, we have problems of no permissions to call pivot_root and create new keyring. In containers.conf, we could disable pivot_root, but we miss an option to disable keyring.

[rhatdan]

These look like they are blocked by seccomp rules. Could you give the actual podman command you are trying to execute?

[gzm55]

1. create docker container:

docker run --rm -it --user test-user \
                   --device /dev/fuse \
                   --cap-add SYS_ADMIN \
                   an-oci-toolset-image sh

2. in the rootless ADMIN container, create a nested container:

podman run --rm -it --net=host --pid=host busybox echo ok

As @rhatdan said, the problem is that the keyctl() syscall is blocked by seccomp, and according to the docker document, this syscall is blocked to prevent containers from using the kernel keyring, which is not namespaced. I can confirm that, using an special seccomp profile with keyctl enabled, the nested container works.

This syscall is blocked for security concern, so I think we should either namspacize the keyring, or provide an option to reuse the current keyring just like each runtime does. The latter one should be reasonable for nested rootless container.

PS:

podman: 2.1.1
ociRuntime: runc 1.0.0-rc10
cgroupManager: cgroupfs
cgroupVersion: v1
kernel: 3.10.0-1127.19.1.el7.x86_64

[rhatdan]

Docker is wrong, keyctl is namespaced. This seccomp statement is dated.
Podman allow these sysctls by default.
Since this is more about how docker sets up the containers that run podman, it is not a podman issue. So I am going to close this issue.
BTW Why not run podman natively or podman inside of podman?

[gzm55]

Docker is wrong, keyctl is namespaced. This seccomp statement is dated.
Podman allow these sysctls by default.
Since this is more about how docker sets up the containers that run podman, it is not a podman issue. So I am going to close this issue.
BTW Why not run podman natively or podman inside of podman?

OK, thanks to figure out the solution.

Some old ci systems are still used to build images inside a docker container, so we need nested containers. And this system communicate to daemon via unix sock. Later we would like to try the new podman rest api, this way should introduce the native rootless nested containers to our systems.

[gzm55]

@rhatdan is this the default seccomp profile used by podman? this does not enable the keyctl syscall.

[gzm55]

@rhatdan
according to containers/common#294
it seems that the keyctl is still under discussion, how is it going?

[rhatdan]

Well we do a small patch for Fedora to allow it. I attempted to get this in the upstream,but was blocked since some older kernels still did not do a decent job of namespacing keyctl. RHEL7 age kernels.

[gzm55]

@rhatdan since keyctl is not merged in the upstream, and RHEL7 is still widely deployed, so native nested podman container still needs the option describe in this issue. can we re-open this issue and consider again?

[rhatdan]

containers/common#354

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

This should be in the main branch now.

[gzm55]

@rhatdan do you mean that the master branch of podman already has a new podman run ... option for disabling creating a new keyring? I tested the latest tag 2.2.1 and searched the commits in the last 3 weeks, and did not see such an option. How can I disable the keyring feature using the latest or development version of podman.

[rhatdan]

There is support in containers.conf for setting all container engines to create or not create the keyring.

keyring tells the container engine whether to create

a kernel keyring for use within the container.

keyring = true

I believe creating $HOME/.config/containers/containers.conf or /etc/containers/containers.conf should do this, if it is fully wired up.

[containers]
keyring=false

[gzm55]

for podman version 2.2.1, podman recognize keyring option. But after setting keyring=false in /etc/containers/containers.conf, we still got the same error about 'create session key'.

[rhatdan]

This was not wired down the stack.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

Looks like this is done in the main branch and podman 3.0.

[hickersonj]

I'm not able to execute a private registry within a container via podman without having the same keyring error. I have added keyring=false, but still the same error:

Error: unable to start container "0dd65ac9fcf3af154e3caefd8ad638430b6929dfce912bbf7886529833088a94": container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: join session keyring: create session key: operation not permitted: OCI permission denied

# strace shows podman is reading the config
read(3, "[engine]\ncgroup_manager=\"cgroupfs\"\nevents_logger=\"file\"\ntmp_dir=\"/tmp/libpod\"\nno_pivot_root=true\nkeyring=false\nconmon_path=[\"/usr/bin/conmon\",]\nruntime=\"/dat"..., 681) = 680

podman version
Version:      3.2.3
API Version:  3.2.3
Go Version:   go1.16.5
Git Commit:   1e6fd46e91b21342f9454cf8105a92b90e398c52
Built:        Thu Aug 12 19:02:50 2021
OS/Arch:      linux/amd64

runc --version
runc version 1.0.1
commit: v1.0.1-0-g4144b63817eb
spec: 1.0.2-dev
go: go1.16.5
libseccomp: 2.5.1

conmon --version
conmon version 2.0.27
commit: 65fad4bfcb250df0435ea668017e643e7f462155

cat ~/.config/containers/container.conf
[engine]
cgroup_manager="cgroupfs"
events_logger="file"
tmp_dir="/tmp/libpod"
no_pivot_root=true
keyring=false
conmon_path=["/usr/bin/conmon",]
runtime="/usr/bin/runc"

Any feedback on this or how to output what podman is sending to the runc run command would be greatly appreciated.