Podman: rootless: permission denied when trying to write to /run/user

[tobwen]

/kind bug

Description
When running _podman_ from an unprivileged user (uid=1001(tobwen) gid=1001(tobwen) groups=1001(tobwen)), _podman_ tried to write to _/run/user_, where the user doesn't have permission on _Debian_.

Steps to reproduce the issue:

1. no _podman_-config file exists (I'm using switches only)
2. all the dependencies (_crun_ etc.) are installed and the paths are correct
3.

/home/tobwen/podman/usr/local/bin/podman \
--conmon /home/tobwen/podman/usr/local/bin/conmon \
--network-cmd-path /home/tobwen/podman/usr/local/bin/slirp4netns \
--runtime /home/tobwen/podman/usr/local/bin/crun \
--storage-driver overlay \
--storage-opt 'overlay.mount_program=/home/tobwen/podman/usr/local/bin/fuse-overlayfs'

Describe the results you received:

ERRO[0000] could not get runtime: error generating default config from memory: cannot mkdir /run/user/0/libpod: mkdir /run/user/0/libpod: permission denied

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Error: could not get runtime: error generating default config from memory: cannot mkdir /run/user/0/libpod: mkdir /run/user/0/libpod: permission denied

Output of podman info --debug:

Error: could not get runtime: error generating default config from memory: cannot mkdir /run/user/0/libpod: mkdir /run/user/0/libpod: permission denied

Package info (e.g. output of rpm -q podman or apt list podman):

built from source with a stack, which worked in the past

Additional environment details (AWS, VirtualBox, physical, etc.):
Debian 10 on Virtual Box 6 on Windows 10 (all 64-bit)

[tobwen]

Looks like a regression, but it does not solve the problem.

https://github.com/containers/libpod/blob/master/troubleshooting.md#4-rootless-could-not-get-runtime---database-configuration-mismatch

[tobwen]

I fixed it: Damn you, _cgroupfs v2_!

doesn't work

su tobwen

works

su -l tobwen

Should we add this to https://github.com/containers/libpod/blob/master/troubleshooting.md ?

[rhatdan]

How did cgroupv2 get in the way?

[rhatdan]

su tobwen would either not set the environment of the user or the environment would stay the same as the caller. I would figure the former. So since the environ was not set, then podman is blowing up since it is thinking that the container is running as root?

[tobwen]

How did cgroupv2 get in the way?

Before switching to cgroupv2, I didn't need to use su -l. It worked with simple su.

su tobwen would either not set the environment of the user or the environment would stay the same as the caller. I would figure the former.

No, I think the latter, since:

$ id
uid=1001(tobwen) gid=1001(tobwen) groups=1001(tobwen)

But the DBUS (I think it was DBUS) env variables are missing. Those get populated only with _linger_ + _su -l_.

So since the environ was not set, then podman is blowing up since it is thinking that the container is running as root?

Exactly.

So two things are needed when not login directly to the user:

loginctl enable-linger $user
su -l $user

Shall I add it to troubleshooting.md via PR?

[mheon]

Loginctl I believe is already mentioned; if it's not, it needs to be.

[rhatdan]

Linger is covered in the troubleshooting @tobwen if you want to add more detail, please open a PR.