### Summary With https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57600, we modified the maven package finder to improve its efficiency. One of the improvements made was to implement https://gitlab.com/gitlab-org/gitlab/-/issues/287638 by using an [existing finder helper](https://gitlab.com/gitlab-org/gitlab/-/blob/f043ace969a4c1488b9b14373ea86b0c49182ed4/app/finders/concerns/packages/finder_helper.rb). This causes an issue for the group level maven api. Given this situation: Group -> Subgroup -> Project Before https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57600: Reporters of `Subgroup` could pull packages from `Project` by using the group level endpoint and targeting `Group`. How is that possible? * Users [need](https://gitlab.com/gitlab-org/gitlab/-/blob/f043ace969a4c1488b9b14373ea86b0c49182ed4/lib/api/maven_packages.rb#L149) the `read_group` permission on the target group (`Group`). * This is [granted](https://gitlab.com/gitlab-org/gitlab/-/blob/f043ace969a4c1488b9b14373ea86b0c49182ed4/app/policies/group_policy.rb#L95-97) by the group policy which basically says if a user has access to any of the subprojects, it has access to the root group with the `read_group` permission. * Users [need](https://gitlab.com/gitlab-org/gitlab/-/blob/f043ace969a4c1488b9b14373ea86b0c49182ed4/lib/api/maven_packages.rb#L153) the `read_package` permission on the project (`Project`). * This is granted by the usual role system where reporters of `Subgroup` will be reporters on the contained projects. * The above will [grant](https://gitlab.com/gitlab-org/gitlab/-/blob/f043ace969a4c1488b9b14373ea86b0c49182ed4/app/policies/project_policy.rb#L261) the `read_package` permission After https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57600: The same scenario will now fail. * Users [need](https://gitlab.com/gitlab-org/gitlab/-/blob/f043ace969a4c1488b9b14373ea86b0c49182ed4/lib/api/maven_packages.rb#L149) the `read_group` permission on the target group (`Group`). * Same as before * Users [need](https://gitlab.com/gitlab-org/gitlab/-/blob/f043ace969a4c1488b9b14373ea86b0c49182ed4/lib/api/maven_packages.rb#L153) the `read_package` permission on the project (`Project`). * Same as before * In addition, users [need](https://gitlab.com/gitlab-org/gitlab/-/blob/f4e9203f9567e233d3269b177e2634f64271466e/app/finders/concerns/packages/finder_helper.rb#L14) `read_package` on the target group (`Group`) * This is a new check * `read_package` on groups is only [granted](https://gitlab.com/gitlab-org/gitlab/-/blob/f4e9203f9567e233d3269b177e2634f64271466e/app/policies/group_policy.rb#L132) to direct reporters (or public groups). * Reporters of `Subgroup` will not have this :boom: ### Possible fixes 1. We could grant `read_package` the [same way](https://gitlab.com/gitlab-org/gitlab/-/blob/f4e9203f9567e233d3269b177e2634f64271466e/app/policies/group_policy.rb#L96) that `read_group` is granted for a Group but that will open things too much to my taste. This increases the risk of leaking private objects. 1. We can modify the package finder helper to enforce `read_group` instead of `read_package`. * This would mimic the same set of permissions checked for Maven APIs before the MR. * The package finder helper is also used by NuGet packages but this is fine as nuget APIs directly [check](https://gitlab.com/gitlab-org/gitlab/-/blob/f4e9203f9567e233d3269b177e2634f64271466e/lib/api/concerns/packages/nuget_endpoints.rb#L60) the `read_package` permission on the group. Solution (2.) is the best one.