toolbox: tty device used inside toolbox gets odd permissions on host causing pinentry/gpg-agent to not work
Describe the bug
My setup includes running gpg-agent on my host and doing development (git commit, etc) inside my toolbox container. When I git-commit I sign the commits, which means the process talks to the agent that then runs a pinentry program to ask the user for the passphrase.
When running in the terminal I prefer for the passphrase to be asked to me in the terminal window and not in a popup. So I’ll unset DISPLAY to force it to use the terminal window. This stopped working sometime in the past few months. I finally tracked down some more information on why.
When running inside toolbox the permissions on my tty device are as expected:
$ ls -l $(tty)
crw--w----. 1 root nobody 136, 14 Sep 27 13:37 /dev/pts/14
However outside of toolbox (from the perspective of the host) the permissions look odd:
[dustymabe@media ~]$ id
uid=1001(dustymabe) gid=1001(dustymabe) groups=1001(dustymabe) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[dustymabe@media ~]$ ls -l /dev/pts/14
crw--w----. 1 100000 tty 136, 14 Sep 27 14:39 /dev/pts/14
I would expect the owner of the tty to be the user who launched the toolbox container (1001). If I change the ownership to the expected UID then my pinentry program appropriately asks for the passphrase on the same terminal window (inside toolbox) where I am running git commit.
I’m running Fedora 33 with:
$ rpm -q toolbox podman
toolbox-0.0.95-1.fc33.x86_64
podman-2.1.0-0.187.rc2.fc33.x86_64
Indeed if I go back to an old machine I haven’t updated in a while I can see that the permissions are what I would expect them to be. This out of date machine has:
[dustymabe@hattop ~]$ rpm -q toolbox podman
toolbox-0.0.18-1.fc31.noarch
podman-1.8.0-2.fc31.x86_64
Steps how to reproduce the behaviour
- Launch toolbox container
- Inspect owner inside the container:
ls -l $(tty). Should show up asrootsince you are inside a user namespace. - Inspect the owner of that same device outside the container and verify the permissions looks weird.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 1
- Comments: 24 (12 by maintainers)
Commits related to this issue
- volumes: allow more options for devpts allow to pass down more options that are supported by the kernel. Discussion here: https://github.com/containers/toolbox/issues/568 Signed-off-by: Giuseppe Sc... — committed to giuseppe/libpod by giuseppe 3 years ago
- volumes: allow more options for devpts allow to pass down more options that are supported by the kernel. Discussion here: https://github.com/containers/toolbox/issues/568 Signed-off-by: Giuseppe Sc... — committed to giuseppe/libpod by giuseppe 3 years ago
- volumes: allow more options for devpts allow to pass down more options that are supported by the kernel. Discussion here: https://github.com/containers/toolbox/issues/568 Signed-off-by: Giuseppe Sc... — committed to giuseppe/libpod by giuseppe 3 years ago
- volumes: allow more options for devpts allow to pass down more options that are supported by the kernel. Discussion here: https://github.com/containers/toolbox/issues/568 Signed-off-by: Giuseppe Sc... — committed to giuseppe/libpod by giuseppe 3 years ago
- volumes: allow more options for devpts allow to pass down more options that are supported by the kernel. Discussion here: https://github.com/containers/toolbox/issues/568 Signed-off-by: Giuseppe Sc... — committed to giuseppe/libpod by giuseppe 3 years ago
Did some testing using podman main at commit 0686f0bb. Using
--mount type=devpts,destination=/dev/pts,uid=1000,gid=5to mount/dev/ptswithuser:ttyownership still didn’t fix the issue. Plus, i have noticed that by usinguidandgidyou lose group write permission for$(tty), which doesn’t happen with--mount type=devpts,destination=/dev/pts.I also tried passing
--volume /dev:/dev:rw, omitting--mountbut not--volume /dev:/dev:rwand viceversa, but nothing seemed to fix the issue. A this point I think that there was a regression or in podman or in gpg-agent, unless my setup is somehow broken, which I don’t think it’s the case since I am running stock fedora silverblue 35 with minimal configuration (changed prompt and added some aliases).By the way, I submitted https://github.com/containers/toolbox/pull/581 for the
--mount type=devpts,destination=/dev/ptschange. @giuseppe had been asking me to do so for a while, so better late than never.