Toolbox vs podman: permission denied /proc/1/exe


I need a nudge in the correct direction.

If I do a “podman run” against the “fedora-toolbox-36” image I can execute “cat /proc/1/exe” with no special flags. However, if I do a “toolbox enter” against a container created with “toolbox create” using that image I get a permission denied from “cat /proc/1/exe”. Looking over toolbox’s create.go code nothing is jumping out at me (except that --privileged is passed!).

I’m clearly missing something fundamental here. Namespaces? Can you nudge me in the right direction?


You need to paste here the exact commands and error messages to let us help you.

This works:

podman run --user 1000:1000 -ti <image> cat /proc/1/exe

This works:

podman run -ti <image> cat /proc/1/exe

This works:

podman run --user 1000:1000 -ti <image> bash
cat /proc/1/exe

This works:

podman run -ti <image> bash
cat /proc/1/exe

This does not work

- toolbox enter
- cat /proc/1/exe
cat: /proc/1/exe: Permission denied

The podman commands are run against the “fedora-toolbox-36” image. Running “toolbox enter” against a container created with “toolbox create” using that image I get a permission denied. No special options were used when creating the toolbox container.

toolbox uses the PID namespace from the host by default. All other commands creates their own PID namespace.

$ podman run --rm -ti --pid host fedora:latest cat /proc/1/exe
cat: /proc/1/exe: Permission denied

Thanks @siosm, I was thinking this might be the case but I’m new to podman so I wasn’t certain how to articulate this correctly.

Is there a method by which I can create/launch a toolbox container in such a manner that I won’t have these namespace issues? I don’t see anything in that would help me. Alternatively, is there a podman route to this? Toolbox is preferred in my case if possible.

This is likely an instance of XY problem - Wikipedia. What do you really want to do?

I’m attempting to shoehorn an antivirus program into a container. (See Malware scanning of /home in Silverblue for background). stracing shows me it’s abending on the cat /proc command. It likely still will not work even after I surmount this problem but it seems worth a try. It’s also a good learning exercise for me on containers.

Then you probably don’t want to use a toolbox container but build your own with the antivirus program in the image and then run it with podman directly and with a volume mount for the data that you want to scan.

Thanks. I won’t be able to do that with this program unfortunately because it’s a funky .rpm which can’t be layered. I was only able to get it to install in a container but it fails to start because it’s trying to grab info from /proc but has no authorization to do so.

journalctl -t ‘rpm-ostree’ gives me this:

Sep 30 11:06:05 fedora rpm-ostree[8348]: Txn UpdateDeployment on /org/projectatomic/rpmostree1/fedora failed: Importing package ‘SentinelAgent’: Importing archive: ostree-tar: Failed to handle file: ostree-tar: Failed to import file: Writing content object: Lzma library error: Corrupted input data

Are non-sequitor. The container image you build will be where you install the rpm as you like with Guix if so desired. You then use that custom built image to create a container from. If I’m not mistaken, you can also point toolbox to a custom image to use as your toolbox. If not try distrobox.

You don’t want to use layering here but container builds via podman or buildah. You probably also want to run it directly via podman so that you can give it the access it want to /proc or whatever.