Remove the `repository` check when authorizing package registry requests with a deploy token
Summary
You can use the Package Registry to publish and install packages in a variety of formats. You can authenticate with personal access, project access, job or deploy tokens.
Problem
- Deploy tokens get access to packages through a special condition in the project policy.
- This works as expected
- Now we have a negative rule that basically says if one of the below is true, all
packages
permissions are removed:- The
packages
feature is disabled - The
repository
feature is disabled
- The
- The ~bug lies when checking the
repository
feature. This check is mainly done by verifying if the user has access to the project feature. - Let's break down how this "has the current user access to this project feature" function:
- if the feature is currently
DISABLED
, well, we returnfalse
- if the feature is currently
PRIVATE
, we check that the current user has the proper minimum access level for the feature - all other cases (including feature is
ENABLED
), we return true
- if the feature is currently
- The problem is that when (2.) is evaluated against a DeployToken object, the backend thinks that it has no access level at all.
- This case will reject the user from getting the
package
permissions.
- This case will reject the user from getting the
Now, here is the interesting part:
- If I create a project with
public
visibility and then make itprivate
, therepository
feature is set toPRIVATE
.- We will end up in (2.) above and thus, we will hit the ~bug
- If I create a project with a
private
visibility, therepository
feature is set toENABLED
.- We will end up in (3.) and the
package
permissions will be granted.
- We will end up in (3.) and the
Proposal
Remove the code that checks the repository
feature when checking package
permissions.
Related issues
- Deploy token epic: &6192
- Feature specific permissions change (this will decouple the repository permissions from the container registry, package registry and lfs: #329253 (closed)
/cc @bufferoverflow @fh1ch @dlouzan @wwwjon @max-wittig
Edited by Tim Rizzi