-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Affects Version/s: 6.19.0
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Severity:Critical
-
Regression:Yes
Unable to resolve packages from virtual repositories when the requesting client doesn’t have any permissions to a repository in the virtual aggregation which is higher in the aggregation order than the repository from which you expect the package to be resolved from, OR there is a permission target with an include pattern configured on the higher-ordered repository.
Steps to reproduce (docker)
- Create a docker local repository (docker-local)
- Create a smart remote docker repository (docker-smartremote) to a local docker repository in a distant Artifactory instance. Supply the relevant admin credentials for the target Artifactory instance (if it needs auth).
- Create a docker remote repository (docker-remote) default to docker hub is fine
- Create a virtual (docker-virtual) which aggregates in order 1)docker-local 2)docker-smartremote 3)docker-remote
- Create a permission target for anonymous & all authenticated users to be able to pull from docker-local and docker-remote
- DO NOT create a permission target for docker-smartremote OR create a permission target with an include pattern (anything but ** or */ catch all) for docker-smartremote
- As an anonymous/unauthenticated user (or anything except an admin user), request an image from docker-virtual that you know exists at docker-remote, e.g. docker pull docker-virtual.artifactory.domain.local/logstash:6.8.1
Expected Behaviour
- Client is able to pull the image via the docker virtual repository – the image is cached in docker-remote-cache
Observed Behaviour
- Client is NOT able to pull the image via the docker virtual repository – the client receives the following error: “unauthorized: The client does not have permission for manifest: Download request for repo:path 'docker-smartremote-cache:logstash/6.8.1/list.manifest.json' is forbidden for user 'anonymous'.”
- The client IS able to pull the image directly from docker-remote (expected > due to perm target created in reproduction step 5)
- The same issue is observed if there is a permission target for docker-smartremote but it has an includes pattern which isn’t a catch all (i.e. not ** or */ - in our case “gr/**” needs to be configured as the includes pattern for the smart remote repositories).
- This cannot be reproduced in Artifactory 6.11.3
The same issue could be reproduced for a NuGet full-mesh.
- relates to
-
RTFACT-21825 Resolution issues with valid permissions in Docker virtual repositories
- Done