API /api/v4/projects endpoint sends back wrong project permissions
Summary
When querying the gitlab.com/api/v4/projects
API endpoint to list projects I am owner of, the correct list of projects is sent back but for some projects, the permissions retreived are not correct. Querying the ID of the project directly (gitlab.com/api/v4/projects/<ID>
) shows the right permissions.
This may create false positives for instance in security scripts that gather permissions for reporting.
Steps to reproduce
See examples below, it does not happen to all projects.
Example Project
What is the current bug behavior?
I am currently owner of the https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-internal/automation/ci_nuclei_scanner repository. If I query the projects
endpoint for projects I owned, I get this project back on page 16 with the following wrong permissions:
% curl --header "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects?owned=true&per_page=1&page=16"
[{"id":41433715,"description":"Use naabu, https, and nuclei to hunt for vulnerabilities","name":"ci_nuclei_scanner","name_with_namespace":"GitLab.com / GitLab Security Department / Threat Management / Red Team / Red Team Internal / Automation / ci_nuclei_scanner",
[..]"
permissions":{"project_access":null,"group_access":null}}]
However, if I query the projects/id endpoint, the correct group permission (50=owner) is retrieved:
% curl --header "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects/41433715"
{"id":41433715,"description":"Use naabu, https, and nuclei to hunt for vulnerabilities","name":"ci_nuclei_scanner","name_with_namespace":"GitLab.com / GitLab Security Department / Threat Management / Red Team / Red Team Internal / Automation / ci_nuclei_scanner",
[..],
"permissions":{"project_access":null,"group_access":{"access_level":50,"notification_level":3}}}
In comparison, retrieving another project I am owner of sends back the correct permission:
curl --header "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/projects?owned=true&per_page=1&page=6"
[{"id":43300541,"description":"Payload-listeners for use during red team operations.","name":"payload-listeners","name_with_namespace":"GitLab.com / GitLab Security Department / Threat Management / Red Team / Red Team Public / payload-listeners",[..],
"permissions":{"project_access":null,"group_access":{"access_level":50,"notification_level":3}}}]
Removing the owned=true
parameter and replacing it with membership=true
to get the list of all projects I am member of does not change the result, the permission is still not the correct one (null instead of 50).
What is the expected correct behavior?
The /api/v4/projects
endpoint should return the correct project permissions, similar to what the /api/v4/projects/<id>
endpoint is doing. We could think that the owned=true
parameter is making the permission info non relevant but the issue occurs also without it, using only the membership=true
parameter.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)