Would be nice to have a different 'podman pull' exit code for authorization failures #10858
Comments
openshift-ci
bot
added
the
kind/feature
|
I don't believe this will be easy to implement, since containers/image, as I understand it, has a hard time differentiating between "authorization required" and image does not exist. @vrothberg @mtrmac WDYT? |
|
Thanks for reaching out, @debarshiray!
That's right (same error even when logged in): Many registries (not sure if all) return auth errors when trying to pull images that do not exist. That would lead to false positives when prompting users to login. |
|
Indeed, this has been asked for several times before but my understand is that until registries send better messages/response codes we cannot differentiate. |
|
There are at least four major cases, with variants:
So the first question is what do you want to do in all of these cases. (That decision could be easier when accessing a hard-coded image, e.g. registry.redhat.io/always-intended-to-be-public:foo ; but with user-specified input it just looks hard.) At the very least note that “provided but invalid credentials” and “missing credentials” are different use cases; “authorization failure” is too vague. Which one do you want to handle, and how? Another question is how to expose this via Podman, and the difficulties from #6190 (comment) / #6190 (comment) still very much apply. (Is the |
|
Ok, thanks for all the prompt and thoughtful responses, everybody. Much appreciated. I have forwarded a summary of this discussion to the downstream distributors pushing for this feature. ;) |
It's not possible to programmatically detect when an image requires logging into the registry [1]. Therefore, instead of trying to handle 'podman pull' failures due to lack of authorization, just mention that private images require 'podman login' and that further details of the failure can be found by using the --verbose option. [1] containers/podman#10858 containers#754
It's not possible to programmatically detect when an image requires logging into the registry [1]. Therefore, instead of trying to handle 'podman pull' failures due to lack of authorization, just mention that private images require 'podman login' and that further details of the failure can be found by using the --verbose option. [1] containers/podman#10858 containers#754 containers#852
It's not possible to programmatically detect when an image requires logging into the registry [1]. Therefore, instead of trying to handle 'podman pull' failures due to lack of authorization, just mention that private images require 'podman login' and that further details of the failure can be found by using the --verbose option. [1] containers/podman#10858 containers#754 containers#852
|
A friendly reminder that this issue had no activity for 30 days. |
|
I don't mind closing this issue because I managed to convince the relevant downstream distributor that this can't be achieved. :) |
github-actions
bot
added
the
locked - please file new issue/PR
/kind feature
Description
This is a lot like #6190 but for authorization failures which is possibly more narrowly defined than network errors.
We are receiving feature requests against Toolbox from downstream distributors to detect when a registry requires the user to log in and handle the authorization by prompting the user as part of the container creation process (ie.,
toolbox create) without requiring users to invokepodman loginon their own.This is motivated to a great extent by coreos/toolbox, which does the same.
However, on a closer look, this isn't easy to implement in a Podman wrapper like Toolbox because it's difficult to know when
podman pullfailed due to lack of authorization.The coreos/toolbox implementation assumes that every
podman pullfailure is an authorization issue. This is sub-optimal because the vast majority of Fedora (or Arch, or Debian, or ...) users won't be using private registries, and they are way more likely to encounter passing network or registry issues.We have an initial implementation for Toolbox that tries to screen scrape the standard error stream of
podman pullto guess the nature of a failure. However, this sort of screen scraping is very fragile and is a bad idea.First, the messages that get dumped in the error stream don't have any fixed structure or format, and can change from one Podman version to another. Moreover, the error stream is also used to show things like progress bars, so those need to be skipped when parsing it. This makes it very fragile to test whether the parsing works as expected across several Podman versions in several operating systems.
Second, since the error stream is also used to show progress bars for
podman pull, redirecting it away from a terminal device (to intercept its contents) prevents the progress bar from being shown. We show the progress bar whentoolbox --verbose ...is used because they are useful for checking the status of the pulls. Ultimately, we are downloading hundreds of megabytes as part of a critical operation, so having access to a working progress bar is important.So, long story short, it would be good if
podman pullhad a dedicated exit code to denote authorization failures.Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):The text was updated successfully, but these errors were encountered: