[fc31,rootless] podman exec: OCI runtime permission denied

[edsantiago]

After upgrading to a working crun, rootless podman sort-of works but exec fails:

$ podman run -d --name foo alpine  sleep 60
39c51869d7ff69cc7536053567e72f9d553070bf1f86ee54caa0ecf0814f5b1f

$ podman exec foo date
Error: writing file '/sys/fs/cgroup//user.slice/user-1000.slice/user@1000.service/user.slice/libpod-39c51869d7ff69cc7536053567e72f9d553070bf1f86ee54caa0ecf0814f5b1f.scope/cgroup.procs': Permission denied: OCI runtime permission denied error

Versions:

$ rpm -qa|egrep 'podman|runc|crun|slirp|iptables|conmon|systemd'|sort
conmon-2.0.1-1.fc31.x86_64
crun-0.10-1.fc31.x86_64
iptables-1.8.3-5.fc31.x86_64
iptables-libs-1.8.3-5.fc31.x86_64
podman-1.6.1-0.4.dev.git7a56963.fc32.x86_64
podman-manpages-1.5.1-3.git0005792.fc31.noarch
podman-tests-1.6.1-0.4.dev.git7a56963.fc32.x86_64
python3-systemd-234-9.fc31.x86_64
python-systemd-doc-234-9.fc31.x86_64
rpm-plugin-systemd-inhibit-4.15.0-0.beta.2.fc31.2.x86_64
slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
systemd-243~rc2-1.fc31.x86_64
systemd-bootchart-233-5.fc31.x86_64
systemd-libs-243~rc2-1.fc31.x86_64
systemd-pam-243~rc2-1.fc31.x86_64
systemd-rpm-macros-243~rc2-1.fc31.noarch
systemd-udev-243~rc2-1.fc31.x86_64

$ uname -r
5.3.0-0.rc5.git0.1.fc31.x86_64

[edsantiago]

Possibly related - lmk if I should open a separate issue:

$ cat Dockerfile
FROM alpine
RUN date

$ podman build -t foo --format=docker .
STEP 1: FROM alpine
STEP 2: RUN date
2019-10-01T18:58:19.000645938Z: sd-bus call: Permission denied
error running container: error creating container for [/bin/sh -c date]: : exit status 1
Error: error building at STEP "RUN date": error while running runtime: exit status 1

[edsantiago]

And another one: [UPDATE: Filed as separate issue, #4164]

$ podman pod create
Error: unable to create pod: unable to create pod cgroup for pod aa6e1f01ed9e08277d1e534eaac8f57cb4aeb05662b8b4cd2ed829da18b9ddf0: error creating cgroup user.slice/user-libpod_pod_aa6e1f01ed9e08277d1e534eaac8f57cb4aeb05662b8b4cd2ed829da18b9ddf0.slice: dial unix /run/user/0/bus: connect: permission denied

[mheon]

The last one is us being unable to talk to systemd... It seems to be trying to talk to root's systemd dbus?

[mheon]

First one and probably second are probably crun, @giuseppe PTAL

[mheon]

@edsantiago Can we get a separate issue for the third one? I think the first two may be related

[edsantiago]

It seems to be trying to talk to root's systemd dbus?

So.... this is a longstanding point of confusion for me. Remember the log-level bug? #4012? One of the spurious warnings that kept getting emitted is:

time="2019-09-16T16:07:44Z" level=warning msg="Failed to add podman to systemd sandbox cgroup: dial unix /run/user/0/bus: connect

(note the 0 in /run/user/0). I still see lots of /run/user/0 warnings in rawhide when running with --log-level=debug; I just ignore them because nobody commented on them in #4012 and because things seemed to mostly work despite that. So I don't know if that's a real bug or a red herring.

Yes, I'll open a new issue for pod create. Thanks.

[mheon]

My bet is that it's using EUID to decide what bus to connect to, which will be 0 (we've already join a user namespace, but not the mount/other namespaces, by the time we try to talk to the bus).

[rhatdan]

Yes that would be a HUGE issue. We should be trying to talk to the USER UID.

[edsantiago]

For benefit of anyone encountering this bug, the workaround is:

$ export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus

[edwintorok]

FWIW this is still an issue on Fedora 32, which ships podman 2.0.4. Could you bump the version in Fedora to include this bugfix? (the workaround above does work though), i.e. setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus instead of DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-YYYedY1u8f,guid=052dde084a153f4f9e0afaee5f4148ac which I got by default)

[mheon]

Podman 2.0.5 should be hitting stable soon, but I'm not sure if it has the fix. Worst case, it will come in Podman 2.1.0 which will release in a week or so.

…

On Thu, Aug 27, 2020, 19:03 Török Edwin ***@***.***> wrote: FWIW this is still an issue on Fedora 32, which ships podman 2.0.4. Could you bump the version in Fedora to include this bugfix? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4162 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCD3BDNFQ2S3GXDU7ZLSC3Q5NANCNFSM4I4NPYOA> .