-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Docker pull fails to pull from restricted path if anonymous access allowed on the other path #2928
Comments
You need a default policy for "base/**" or else the logged in users won't have access. |
Oh, okay, will check tomorrow. |
@andaaron does not work. The same issue as reported:
|
And podman works as expected, even without
|
@andaaron and, as i reported, if i delete all anonymousPolicy, then docker works:
|
Well, that bug is a complete show stopper to replace Harbor. |
If podman works and docker client doesn't, what calls are they making differently? Maybe docker is calling an additional API? Should check zot logs for the calls being made. |
@andaaron the main difference what happens after Podman (when /v2/ - 200) - successful:
Podman (when /v2/ - 401) - successful
Docker (when /v2/ - 200) - failed:
Docker (when /v2/ - 401) - successful:
|
So podman simply always send credentials after call to |
I don't think we should return 401 on /v2 if anonymous access is allowed on other repos, as we don't know what repos the client would try to access next. |
@eusebiu-constantin-petu-dbk you worked more on this side, where was the expected behavior of /v2 discussed/documented in the community? |
https://github.com/opencontainers/wg-auth/blob/main/docs/implementations/moby.md They decide to setup basic auth on further requests based on /v2/ route and not if credentials are set, unlike all other tools. |
I think we could check and see if the client is docker and add logic to return 401 for /v2 based on that, even if anonymous auth is available. The question is if that would break the behavior for other docker clients who are accessing repos which do not require authentication. It would require every docker client to authenticate regardless of the repo they access. How do other registries solve this? |
We can't guess what will be the requested repo based on the initial /v2 call. |
I'd guess better just to see what distribution is doing. In my case Harbor
succesfully pulled by both docker and podman on public (with and without
login), and private (with login).
сб, 1 февр. 2025 г. в 11:06, Andrei Aaron ***@***.***>:
… We can't guess what will be the requested repo based on the initial /v2
call.
—
Reply to this email directly, view it on GitHub
<#2928 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHZ4UBUWAQ2SWBHMBASQCL2NSMCZAVCNFSM6AAAAABWFUZRLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRYHA4DOMRRHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Distribution https://github.com/distribution/distribution/blob/main/docs/content/spec/api.md.tmpl#L298 mentions "Depending on access control setup, the client may still have to authenticate against different resources, even if this check succeeds.", so theoretically the clients should be able to handle authentication on other endpoints if needed. |
I reproduced locally.
This fixes it for authenticated users, but it doesn't work for anonymous ones. |
This is the harbor commit fixing the issue: goharbor/harbor@08f9ffa, they had the same problem. I also found some distribution docs mentioning the same logic as in https://github.com/opencontainers/wg-auth/blob/main/docs/implementations/moby.md. So I think it's clear how they resolve this issue. |
@vooon, a workaround I can think of is disabling anonymous access, and sharing a known user/password with everyone who needs anonymous access. Given the docker specific behavior for /v2, we will very likely not fix this issue. |
Doesn't podman/docker read the credentials from local files also in case of mockbuild? |
@andaaron as i remember no - it doesn't. There were a lot of headache when RH changes python macroses so they no longer works in a simple rpmbuild. There were a lot of pocking around, but easiest was just open anonymous access to the base image. Anyway it doesn't have anything proprietary, just preinstalled dev tools and few setup scripts. The problem that I had to use Docker for GitLab CI because of funky network errors when you utilise services in tests. |
@vooon docker "boostraps" authN based on what it encounters on "/v2/" endpoint and assumes/reuses that for all other endpoints, which can get tricky when we have mixed mode authN such as "anonymous". zot handles each endpoint independently, probably what podman also does. |
@rchincha i understand, but still i have requirement to support docker and having both private and public registries. Looks like easiest if i just catch /v2/ calls on the LB and return 401 unconditionally. |
zot version
2.1.3-rc1 (master)
Describe the bug
So, there a some base images, that i want any clients to be able to pull, but rest of the images - only for logged users.
Without login I'm able to pull
repo.tld/base/foo:bar
, but notrepo.tld/service/baz:latest
, that's expected.Once i've done
podman login repo.tld
anddocker login repo.tld
, i canpodman pull repo.tld/service/baz:latest
, but not the docker one!From the Zot log i see that it does:
GET /v2/
, without auth, 200 OKHEAD /v2/service/baz/manifests/latest
, 401If there no anonymous access allowed flow:
GET /v2/
, - 401HEAD /v2/service/baz/manifests/latest
, with auth - 200 OKTo reproduce
docker/27.5.1 go/go1.22.11 git-commit/4c9b3b0
Expected behavior
Docker pulls protected images when there also anonymous access allowed for some other path.
Screenshots
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: