podman: Error creating /run/user/0/containers on podman login

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

Description

On a fresh Fedora 27 Cloud Base image, I ran dnf update && dnf install podman buildah, then ran this:

[fedora@buildah-fresh ~]$ sudo su -
[root@buildah-fresh ~]# podman login quay.io
Username: rturk
Password:
error creating directory "/run/user/0/containers": mkdir /run/user/0/containers: no such file or directory
[root@buildah-fresh ~]#

Describe the results you expected:

I expected to successfully log in, but was not able to.

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

If I run mkdir -p /run/user/0/containers, I am able to successfully log in subsequently.

[root@buildah-fresh ~]# mkdir -p /run/user/0/containers
[root@buildah-fresh ~]# podman login quay.io
Username: rturk
Password:
Login Succeeded!

Asked a colleague, ipbabble, who does not have a /run/user/0 directory and is somehow able to successfully run podman login.

Output of podman version:

Version:       0.2.2
Go Version:    go1.9.4
OS/Arch:       linux/amd64

Additional environment details (AWS, VirtualBox, physical, etc.):

Fedora Cloud Base 27, running in Red Hat OpenStack Platform:

[root@buildah-fresh ~]# cat /etc/redhat-release
Fedora release 27 (Twenty Seven)

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 54 (39 by maintainers)

Most upvoted comments

I suspect the issue is that we did most of our dev/testing under Fedora workstation & similar. If it’s as simple as creating /run/user/$UID if it doesn’t exist, we can do that easily. I’d like to read more on XDG_RUNTIME_DIR before putting that in, though.

mheon on Mar 1, 2018

I did bit of googling and read some docs and see that directory in /run/user/<UID> is created by pam_systemd which sets default XDG_RUNTIME_DIR.

From freedesktop org docs it states, pam_systemd — Register user sessions in the systemd login manager. So below is what I see is happening.

If you login with an user, the corresponding /run/user/<UID> is created by systemd-logind.service (pam_systemd).

$ ssh root@fedoravm.example.com

# ll /run/user/
total 0
drwx------. 3 root root 80 Mar  1 04:50 0

$ ssh sunilc@fedoravm.example.com

$ ll /run/user/
total 0
drwx------. 3 root   root   80 Mar  1 04:50 0
drwx------. 3 sunilc sunilc 80 Mar  1 04:51 1000

On the other hand if you login with X user and then su to Y user, then the directory is not created for Y user. Because the Y user has not logged in through systemd-login.

$ ssh sunilc@fedoravm.example.com

[sunilc@svma ~]$ su -
Password: 

# ll /run/user/
total 0
drwx------. 3 sunilc sunilc 80 Mar  1 04:52 1000

sunilcio on Mar 1, 2018

Re-posting from https://github.com/containers/image/pull/424 to keep the conversation in one place:

I’m not convinced about auto-creating /run/user/$UID; /run/user is, at least on my system, root:root 755, so any non-root user is not going to benefit.

It seems to me that if the real fix for that needs to be in some quite different place.

Looking at pam_systemd(8), it removes /run/user when “the last concurrent session of a user ends”; so, if we created the directory without systemd knowing about the session, it can delete the directory at an unpredictable time when some other session terminates.
At least on F26, I do have pam_systemd configured in the system-auth config, which is used by su. The failure is actually

pam_systemd(sudo:session): Cannot create session: Already running in a session

So, overall, either pam_systemd needs to be taught to handle su, or we need to move away from /run/user, or we would have to give up on su/sudo (which seems untenable).

mtrmac on Mar 6, 2018

FYI, if I follow those commands up with another podman pull without --creds, it does not work:

[fedora@buildah-fresh ~]$ sudo podman pull quay.io/rturk/nginx
Trying to pull quay.io/rturk/nginx:latest...
Failed
error pulling image "quay.io/rturk/nginx": error pulling image from "quay.io/rturk/nginx": Error determining manifest MIME type for docker://quay.io/rturk/nginx:latest: unauthorized: access to the requested resource is not authorized

rossturk on Mar 1, 2018