Gitlab backend does not respect a repository permission given to a user from its group memberships
See original GitHub issueFollowing https://github.com/netlify/netlify-cms/issues/2069
Describe the bug
With the backend gitlab
, netlifycms refuses login to a user which has write access given through its membership of group, which has itself write permission.
To Reproduce On Gitlab:
- create a group (organization)
test-group
- create a subgroup,
test-group/test-subgroup
- to
test-subgroup
add auser
(do not use the user ownder of the root grouptest-group
) as a member, with write access,developer
(which should be enough for netlifycms to write into a repository) - create a new project repository to the root group,
test-group/test-repository
- on the repository settings of
test-group/test-repository
, atsettings/members
, clickinvite group
, and invite the grouptest-group/test-subgroup
withdeveloper
access - be sure that your
user
, member (developer) of thetest-group/test-subgroup
, is not a member/owner oftest-group
; otherwise this user will already inherit write permissions to all projects nested under the root grouptest-group
On your machine:
- clone netlifycms, and follow the contribution instructions at https://github.com/netlify/netlify-cms/blob/master/CONTRIBUTING.md to setup the project
- at the path
netlify-cms/dev-test/ replace the files
config.ymland
index.htmlby the files with the same name, located at the path
netlify-cms/dev-test/backends/gitlab/ - in the new file
netlify-cms/dev-test/config.yml
, replace the value of the keybackend.repo
, bytest-group/test-repository
(create at the step 4. of the previous “reproduce” section) - run the netlifycms server locally, the homepage should show a
login with Gitlab
button. Click it to log in with your user account, the one that has been added as a member oftest-group/test-subgroup
. - It should show the error
Your GitLab user account does not have access to this repo.
- Even with this netlifycms error, your user should have read/write access to
gitlab.com/test-group/test-repository
; this is Gitlab’s web interface.
Expected behavior
Following Gitlab’s security model, the permissions allowing this user to write to the test-group/test-repository
are granted from its membership to test-group/test-subgroup
. Since this subgroup has been added as a member
(developer) in test-group/test-repository
, it should give write access.
With this setup, Gitlab’s interface allows the user to see and write to the repository.
Applicable Versions:
- Netlify CMS version: latest from master
- Git provider: Gitlab
- OS: linux
- Browser version: firefox, chromium
CMS configuration
The one located here, https://github.com/netlify/netlify-cms/blob/master/dev-test/backends/gitlab/config.yml, with the backend.repo
key from the test repo described in the reproduce steps above.
Test notes The issue seems to be coming from here https://github.com/netlify/netlify-cms/blob/0755f90142525d94158c1d112a5549e21eef77c2/packages/netlify-cms-backend-gitlab/src/API.ts#L176-L186
In the request’s response, there are no permissions under the key permissions
, but authorized groups are listed under the key shared_with_groups
. This issue also seems to reference this aspect of Gitlab’s api https://gitlab.com/gitlab-org/gitlab-foss/issues/39154
From Gitlab’s documentation, this point seems to be of interest https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project-including-inherited-members
A query to this endpoint returns an array of users, each of them having a key access_level
(number). Maybe we can use this to check if the user trying to log in has the permission to write to the netlifycms backend repository
Notes:
- Hope this is clear! Not the easiest to reproduce with all this group/sub-group mess.
- I think I am understanding Gitlab’s security model with group and sub-group permissions correctly, but I am also maybe making an appreciation mistake.
Cheers!
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:6 (4 by maintainers)
@hugurp Looking at
shared_with_groups
is not enough as the branch can be protected:Trying to test this now.
Oh I think I got it to reproduce with your help:
