Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1697011

Summary:	Podman doesn't retain authentication credentials on reboot
Product:	Red Hat Enterprise Linux 7	Reporter:	Mike Rochefort <mroche>
Component:	podman	Assignee:	Brent Baude <bbaude>
Status:	CLOSED NOTABUG	QA Contact:	Martin Jenner <mjenner>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.6	CC:	dwalsh, eparis, fkluknav, jligon, lsm5, mheon, mkeedlinger, oarribas, umohnani
Target Milestone:	rc	Keywords:	Extras
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-04-07 09:30:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mike Rochefort 2019-04-07 03:13:19 UTC

Description of problem:

After rebooting the system (bare-metal/VM) any registries previously logged into through podman are no longer signed in, forcing the user to redo the login process.


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

Version:       0.12.1.2
Go Version:    go1.10.3
OS/Arch:       linux/amd64

How reproducible: Every reboot


Steps to Reproduce:
1. Login to a registry (tested with docker.io and registry.access.redhat.com)
2. Reboot
3. Either push an image to an owned registry or try and logout of a previously logged in registry.

Actual results:

User is no longer signed in to the registry, so authentication fails.


Expected results:

User would remain logged in to a registry after a system reboot.


Additional notes:

This was tested as the root user of a system (U/GID=0). The /run/user/0/containers directory that stores the auth.json file is missing after the reboot process.

Comment 2 Mike Rochefort 2019-04-07 03:24:51 UTC

Clarification: I meant registry.redhat.io, not registry.access.redhat.com.

Cheers,
Mike

Comment 3 Daniel Walsh 2019-04-07 09:30:08 UTC

This is intentional.

If you want to store you credentials in a permanent location you need to specify the --authfile option.

The login credentials is storing the username/password in clear text and should not be left on systems by default.

Comment 4 Mike Rochefort 2019-04-07 15:17:05 UTC

Thanks Dan! Sorry (again) for the non-bug report. Learning something new every-day about podman.

Cheers,
Mike

Comment 5 mkeedlinger 2020-01-21 23:17:13 UTC

Hi, I am having the same issue.

I understand the security implications, but should I desire to commit this taboo and save my credentials between reboots, how would it be done?

I've run `podman login --authfile ~/.podmanauth` and it successfully saved to a file. I have also set REGISTRY_AUTH_FILE to that same location. After having done this, trying to log in or push a container still fails to function as expected.

Am I missing something?

Thanks!

Comment 6 Daniel Walsh 2020-01-24 04:52:20 UTC

If you have REGISTRY_AUTH_FILE pointing at a working ~/.podmanauth, then it should work.  If not this is a bug.

Can you run this with debug and see if there are any debug messages.

Comment 7 mkeedlinger 2020-01-24 16:20:33 UTC

Hi,

I don't see a podman flag for debug in the `--help`. Do you mean `--trace`?

Here's some output that might be telling (lightly redacted to remove useless/private info).

```sh
% podman push [REGISTRY_URL]/python:latest
Getting image source signatures
Error: Error copying image to the remote destination: Error trying to reuse blob sha256:dd5242c2dc8ae9782b73f83281625f45bd6217dc79540e1019d5da0913b491b0 at destination: unexpected http code: 403 (Forbidden)

% echo $REGISTRY_AUTH_FILE 
/home/mkeedlinger/.podman-auth.json

% ls $REGISTRY_AUTH_FILE 
/home/mkeedlinger/.podman-auth.json

% mkdir -p /run/user/1000/containers/         

% cp $REGISTRY_AUTH_FILE /run/user/1000/containers/auth.json

% podman push [REGISTRY_URL]/python:latest
Getting image source signatures
Copying blob sha256:e6d60910d0565ce211523d456096059cc73c82ecc0b7ba561d751797d7adebc7
Copying blob sha256:b52c1c103fae115e0eaee11d9818b25ea03733a5a3b04e98fdfefaefca22cc62
Copying blob sha256:dd5242c2dc8ae9782b73f83281625f45bd6217dc79540e1019d5da0913b491b0
Copying blob sha256:f63773c65620e6b235333fcfcb37ae72f1a21251cd02367ea46f50d78ed95f87
Copying blob sha256:07aa3e49712193568d2e5f936b5cc3dc86319593e07f56d82b59f6d2dbe6f879
Copying blob sha256:6f1c84e6ec59994a62846d628bc155af1dd390386407a3d9f12f77bc783dde5b
Copying blob sha256:9f1e17ec91921e9a0aeba1cb60e20a55eecd4e9113bec8d40db77a3813719b21
Copying blob sha256:c664d35d040952fafef8055db3a1e48718191a2b6e9e4bcfce464c3efeb22e0d
Copying blob sha256:98db0f6b946f7bab9ffc4d2eac02ea62504e2086968fb1be15ce9a32aef0c171
Copying blob sha256:79954c8e59c9f2cac02646e3d742606cab3981f0a68ab120b177bd9ca30a666c
Copying config sha256:00cf1da7dcc8507ace6a2ef5d3c94718d5cb718df582c14d5c03e87ce53bb761
Writing manifest to image destination
Storing signatures
```

As you can see, it is somehow totally missing the REGISTRY_AUTH_FILE env var. I don't think it should matter, but I am using Gitlab's registry.

Comment 8 Daniel Walsh 2020-01-29 12:04:18 UTC

podman --log-level debug ...

Comment 9 Eric Paris 2020-06-04 16:16:19 UTC

For people who stumble in here like me, I found that doing:

podman login --auth-file=${HOME}/.docker/config.json

Will cause podman to write the creds where docker would have written them. Podman will look there for creds without having to set the magic env var.