skopeo login issues errors when run unprivleged

[joequant]

When I run skopeo login as unprivileged, I get

(base) [joe@big-apple master (master)]$ skopeo login docker.io FATA[0000] error reading auth file: error reading JSON file "/run/containers/1000/auth.json": open /run/containers/1000/auth.json: permission denied

Also when I do a skopeo copy of a podman image it sometimes works, and sometimes gives me

time="2020-06-08T03:00:17+08:00" level=fatal msg="Error initializing destination docker://joequant/nextcloud:latest: error getting username and password: error reading JSON file \"/run/containers/0/auth.json\": open /run/containers/0/auth.json: permission denied" time="2020-06-08T03:00:17+08:00" level=error msg="exit status 1"

Suspect that there is some issue with the logic for getting authentication information as an unprivileged user, and in any case the error msg should give some more information as to what is actually broken and how to fix.

[TomSweeneyRedHat]

@joequant thanks for the issue, @QiWang19 can you PTAL?

[mtrmac]

The error messages do report precisely the file access errors reported by the kernel.

• Are the listed files accessible as the relevant users?
• What operating system is this?
• If on Linux, what init system / environment?
• What version of Skopeo?

[joequant]

skopeo 1.0.0 running on a Mageia development system. I'm the packager of skopeo for Mageia linux.

The odd thing is that the files aren't accessible to non-privileged users and when I look at the directory via root, the files do not exist. What it looks like is that skopeo is trying to get authentication information from a place where podman is not storing the information, so it looks like a API mismatch.

if there is an API documentation on where podman is storing authentication information, I can take a look at it to see where the mismatch is.

On Mon, Jun 8, 2020 at 10:10 PM Miloslav Trmač notifications@github.com wrote:

The error messages do report precisely the file access errors reported by the kernel.

• Are the listed files accessible as the relevant users?
• What operating system is this?
• If on Linux, what init system / environment?
• What version of Skopeo?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/containers/skopeo/issues/942#issuecomment-640635463, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWGAGM2WCGY4ZUGPLNHXM3RVTWLVANCNFSM4NXVCGHQ .

[mtrmac]

Is the innermost directory that does exist writable by the relevant user? E.g. if /run/containers/1000/ were only writable by root, not UID 1000, that would explain the failure.

(Some situations like that come up with combinations of su/sudo/pam_systemd .)

[joequant]

What's odd is that the directories it is looking for do not exist. The outer directories are not readable which is the immediate trigger for the problem, but the deeper issue seems to be that it's looking for authentication information in a place where it isn't stored.

It does work sometimes, and when it works the directories are there and have the right permissions. Then something happens and the authentication info disappears.

This might be a bug in podnan rather than skopeo.

在 2020年6月9日 週二 01:33，Miloslav Trmač notifications@github.com 寫道：

Is the innermost directory that does exist writable by the relevant user? E.g. if /run/containers/1000/ were only writable by root, not UID 1000, that would explain the failure.

(Some situations like that come up with combinations of su/sudo/ pam_systemd .)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/containers/skopeo/issues/942#issuecomment-640769794, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWGAGIWSHFIVB5WXGBC7JDRVUOIDANCNFSM4NXVCGHQ .

[mtrmac]

My bet would be https://github.com/containers/libpod/issues/427#issuecomment-370920978 .

[vrothberg]

Are we missing to unshare and join the user namespace?

[rhatdan]

Skopeo login should not need to join a namespace

[rhatdan]

This looks like a systemd session was not established. skopeo login should be smart enough to realize that the directory does not exists and fall back to the auth file in the home dir. @QiWang19 PTAL

[mtrmac]

skopeo login should be smart enough to realize that the directory does not exists and fall back to the auth file in the home dir.

Right now, the /run path is the only one that is ever written, on Linux. So are we going to automatically fall back to non-/run paths? That would remove (violate?) the security promise that “podman login does not store credentials in plain-text on disk”.

[rhatdan]

I guess the answer then is to environment variable

export REGISTRY_AUTH_FILE=path

Or set XDG_RUNTIME_DIR.

[n1603]

Just a note, faced this issue on CentOS7 when I happened to switch to non-root user using "su " from root and performed build activities with skopeo. Properly login as non root user (using "su - non-root-user" from root or login directly as non-root-user using ssh) did not give this issue which aligns with what @rhatdan suggested. XDG_RUNTIME_DIR variable does not need to be set explicitly as such.

[vrothberg]

Thanks for the note, @n1603! You can su --login which will properly set up XDG_RUNTIME_DIR along with the environment.

[n1603]

@vrothberg, yes thats correct. Thanks.

[megabreit]

I ran into a similar issue today. Neither XDG_RUNTIME_DIR nor REGISTRY_AUTH_FILE fixed it. Skopeo always tried to create /run/containers. skopeo version is 1.11.2-dev from RHEL 8 UBI image distribution and it was running inside an unprivileged Openshift container. My "final" solution was to create an empty-dir and mount it to /run. Opening permission to 777 in the image would also be an option. Still this is quite unexpected.