Bug 1891220 - Unable to run podman rootless, Error: cannot re-exec process
Summary: Unable to run podman rootless, Error: cannot re-exec process
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: podman
Version: 31
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Giuseppe Scrivano
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-24 14:33 UTC by Peter Portante
Modified: 2020-11-24 20:17 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-11-24 20:17:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Peter Portante 2020-10-24 14:33:21 UTC
Description of problem:

As a non-root user, the following command fails:

  podman --log-level=debug run -it --name demo --rm centos:8 /bin/bash


Version-Release number of selected component (if applicable): podman 2.0.1


How reproducible: Every time


Steps to Reproduce:
1. podman --log-level=debug run -it --name demo --rm centos:8 /bin/bash

Actual results:

INFO[0000] podman filtering at log level debug
DEBU[0000] Called run.PersistentPreRunE(podman --log-level=debug run -it --name demo --rm centos:8 /bin/bash)
DEBU[0000] Ignoring libpod.conf EventsLogger setting "/home/pportant/.config/containers/containers.conf". Use "journald" if you want to change this setting and remove libpod.conf files.
DEBU[0000] Using conmon: "/usr/bin/conmon"
DEBU[0000] Initializing boltdb state at /home/pportant/.local/share/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /home/pportant/.local/share/containers/storage
DEBU[0000] Using run root /run/user/1000/containers
DEBU[0000] Using static dir /home/pportant/.local/share/containers/storage/libpod
DEBU[0000] Using tmp dir /run/user/1000/libpod/tmp
DEBU[0000] Using volume path /home/pportant/.local/share/containers/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] Not configuring container store
DEBU[0000] Initializing event backend file
WARN[0000] Error initializing configured OCI runtime kata: no valid executable found for OCI runtime kata: invalid argument
DEBU[0000] using runtime "/usr/bin/runc"
DEBU[0000] using runtime "/usr/bin/crun"
DEBU[0000] using runtime "/usr/bin/crun"
Error: cannot re-exec process

Expected results:

(container running centos:8 image)
[root@5a980f122524 /]#

Additional info:

[pportant@gandalf images]$ cat /proc/sys/user/max_user_namespaces
127869
[pportant@gandalf images]$ cat /etc/sub
subgid      subgid-     subuid      subuid-     subversion/
[pportant@gandalf images]$ cat /etc/sub*
pportant:100000:65536
anisha:165536:65536
pbench:231072:65536
hkhalid:296608:65536
jkaufman:362144:65536
pportant:100000:65536
anisha:165536:65536
pbench:231072:65536
hkhalid:296608:65536
pportant:100000:65536
anisha:165536:65536
pbench:231072:65536
hkhalid:296608:65536
jkaufman:362144:65536
pportant:100000:65536
anisha:165536:65536
pbench:231072:65536
hkhalid:296608:65536
cat: /etc/subversion: Is a directory
[pportant@gandalf images]$ id
uid=1000(pportant) gid=1000(pportant) groups=1000(pportant),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[pportant@gandalf images]$ id anisha
uid=1001(anisha) gid=1001(anisha) groups=1001(anisha)
[pportant@gandalf images]$ id pbench
uid=1002(pbench) gid=1002(pbench) groups=1002(pbench)

Comment 1 Lokesh Mandvekar 2020-10-26 12:35:24 UTC
Hi Peter, have you tried v2.1.1?

Comment 2 Peter Portante 2020-10-26 13:16:31 UTC
[pportant@gandalf ~]$ podman run -it --name demo --rm centos:8 /bin/bash
Error: cannot re-exec process
[pportant@gandalf ~]$ podman --version
podman version 2.1.1

Comment 3 Matthew Heon 2020-10-26 13:25:51 UTC
Adding Giuseppe to CC - this looks like the rootless C code failing.

Comment 4 Daniel Walsh 2020-10-27 18:35:54 UTC
What does 

$ podman unshare cat /proc/self/uid_map

output?

Comment 5 Peter Portante 2020-10-27 19:09:29 UTC
[pportant@gandalf ~]$ podman unshare cat /proc/self/uid_map
Error: cannot re-exec process

Comment 6 Daniel Walsh 2020-10-27 20:44:58 UTC
Do you have a podman running in your user session?

ps -ef | grep podman

filecap /usr/bin/newuidmap; filecap /usr/bin/newgidmap 
set       file                 capabilities  rootid
effective /usr/bin/newuidmap    setuid
set       file                 capabilities  rootid
effective /usr/bin/newgidmap    setgid

Comment 7 Peter Portante 2020-10-27 20:55:04 UTC
[pportant@gandalf rpm]$ ps -ef | grep podman
pportant 1454363 3096635  0 16:51 pts/1    00:00:00 grep --color=auto podman

[pportant@gandalf rpm]$ filecap /usr/bin/newuidmap; filecap /usr/bin/newgidmap
set       file                 capabilities
effective /usr/bin/newuidmap     setuid
set       file                 capabilities
effective /usr/bin/newgidmap     setgid
[pportant@gandalf rpm]$

Comment 8 Daniel Walsh 2020-10-27 21:01:55 UTC
Ok I am out of options. Looks like something is going wrong when it creates the usernamespaced podman.
Giuseppe any ideas?

Comment 9 Peter Portante 2020-10-27 21:11:17 UTC
If you want to hop on the box and debug let me know.

I can also try to update to Fedora 32 or 33 and retry.

Comment 10 Daniel Walsh 2020-10-27 21:20:32 UTC
By anychance do you have your homedir mounted noexec or nosuid?

Comment 11 Peter Portante 2020-10-27 21:42:39 UTC
[pportant@gandalf images]$ sudo mount

/dev/mapper/system-home on /home type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=16367324k,nr_inodes=4091831,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/mapper/system-root on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19913)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,seclabel)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel)
/dev/mapper/system-var on /var type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/sda2 on /boot type ext4 (rw,relatime,seclabel)
/dev/mapper/system-var_log on /var/log type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/system-var_tmp on /var/tmp type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/system-opt on /opt type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/42 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=3277644k,mode=700,uid=42,gid=42)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=3277644k,mode=700,uid=1000,gid=1000)
tmpfs on /run/netns type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

Comment 12 Giuseppe Scrivano 2020-10-28 09:52:03 UTC
could you show me the output for:

$ cat /proc/sys/user/max_user_namespaces

$ unshare -U sleep 100 &
$ newuidmap $! 0 $(id -u) 1 1 100000 65536
$ newgidmap $! 0 $(id -g) 1 1 100000 65536

Comment 13 Peter Portante 2020-10-28 11:11:43 UTC
[pportant@gandalf images]$ cat /proc/sys/user/max_user_namespaces
127869

# The above has not changed since I posted this bug, see the "additional info" section of the description.


[pportant@gandalf images]$ unshare -U sleep 100 &
[1] 1537131
[pportant@gandalf images]$ jobs
[1]+  Running                 unshare -U sleep 100 &
[pportant@gandalf images]$ newuidmap $! 0 $(id -u) 1 1 100000 65536
[pportant@gandalf images]$ newgidmap $! 0 $(id -g) 1 1 100000 65536
[pportant@gandalf images]$ jobs
[1]+  Running                 unshare -U sleep 100 &
[pportant@gandalf images]$ ps jx
   PPID     PID    PGID     SID TTY        TPGID STAT   UID   TIME COMMAND
 147540  147554  147540  147540 ?             -1 S     1000   0:18 sshd: pportant@pts/0
 147554  147558  147558  147558 pts/0    1537147 Ss    1000   0:08 -bash
      1  294224  294224  294224 ?             -1 Ss    1000   0:01 /usr/lib/systemd/systemd --user
 294224  294234  294224  294224 ?             -1 S     1000   0:00 (sd-pam)
 294224  294359  294359  294359 ?             -1 Ss    1000   0:00 /usr/bin/dbus-broker-launch --scope user
 294359  294360  294359  294359 ?             -1 S     1000   0:00 dbus-broker --log 4 --controller 11 --machine-id dece48160fd04636874c91c57e2a853c --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000
 751901  751915  751901  751901 ?             -1 S     1000   0:00 sshd: pportant@pts/4
 751915  751917  751917  751917 pts/4     751917 Ss+   1000   0:00 /bin/sh
 294224  896590  896590  896590 ?             -1 Ssl   1000   0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
1133593 1133604 1133593 1133593 ?             -1 S     1000   0:01 sshd: pportant@pts/2
1133604 1133609 1133609 1133609 pts/2    1133609 Ss+   1000   0:00 -bash
 147558 1537131 1537131  147558 pts/0    1537147 S     1000   0:00 sleep 100
 147558 1537147 1537147  147558 pts/0    1537147 R+    1000   0:00 ps jx
      1 3096634 3096604 3096604 ?             -1 S     1000   4:58 mosh-server new -c 256 -s -l LANG=en_US.UTF-8
3096634 3096635 3096635 3096635 pts/1    3096635 Ss+   1000   0:15 -bash

Comment 14 Giuseppe Scrivano 2020-10-28 11:38:13 UTC
Thanks, the issue seems to be in Podman as newuidmap/newgidmap work fine.  Do you have a /run/user/1000/libpod/pause.pid file?  If you do, what is its value?

If it is possible, I could try accessing your node and see what is happening.

Comment 15 Peter Portante 2020-10-28 11:47:19 UTC
[pportant@gandalf images]$ ls -ld /run/user/1000/libpod/pause.pid
-rw-------. 1 pportant pportant 7 Aug  9 23:36 /run/user/1000/libpod/pause.pid

[pportant@gandalf images]$ cat /run/user/1000/libpod/pause.pid
2214917<NO EOL>

I'll contact you offline about accessing the machine directly.

Comment 16 Giuseppe Scrivano 2020-10-28 14:30:15 UTC
it seems the error could be triggered by having an invalid pause pid file, as well as an invalid conmon pid file pointing to another process.

In this case the best solution is to use "podman system migrate" and restart the pause process.

I've opened a PR to give a better error message when it happens: https://github.com/containers/podman/pull/8173

Comment 17 Ben Cotton 2020-11-03 17:11:16 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 Ben Cotton 2020-11-24 20:17:32 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.