Page MenuHomePhabricator

GitLab group permissions are not inherited by sub-groups for groups of users invited to the parent repo
Open, Stalled, LowPublic

Description

Moving this from T293741:

@aborrero writes:

I tried creating a subgroup:

https://gitlab.wikimedia.org/repos/cloud/toolforge

I was able to add the WMCS staff group wmf-team-cloud-services to this subgroup:

https://gitlab.wikimedia.org/groups/repos/cloud/toolforge/-/group_members?tab=groups

Perhaps out of scope for this particular ticket, but I was unable to give permissions to volunteer-group-cloud-admin.

Or is there some kind of inheritance from the parent group?

I wrote:

One thing that's non-obvious - and that we should probably try to make extremely clear to folks - is that if you're a member of a parent group, you're a member of all groups it contains. (This is why we aren't using something with hierarchy like people/wmf/team-cloud-services to model things.)

I had expected that this worked the same for groups, and that anyone in both people/wmf-team-cloud-services and people/volunteer-group-cloud-admin should already have been an owner in cloud/toolforge, but I guess maybe this only holds for direct members of a group:

https://docs.gitlab.com/ee/user/group/#share-a-group-with-another-group

I think this looks like the known problem upstream: Group Permission Inheritance not working as intended

I need to read that thread and see whether it seems like there's a workaround, or any intention of changing the behavior. I'm also noting that while I think I have the right mental model of what's going on here, it's late and the day and trying to be sure is giving me a headache, so I should set up a test case and make sure this is the same problem.

Event Timeline

brennen changed the task status from Open to Stalled.Mar 16 2022, 7:20 PM
brennen triaged this task as Low priority.

I think this should be less relevant to us now that we're not (by default, at least) using people/ groups.

Attempting to summarize this in a way that will make sense to me in the future.

tl;dr: group member permissions only survive a single level of indirection. After that: they vanish.

A person added to a project, that is added to another project, that is added to another project does not have the permissions they expect on that project.

Simple example

This does work, thcipriani can push to ProjectB/Subproject:

- ProjectA:
  - members: [thcipriani:owner]
- ProjectB:
  - members: [ProjectA:owner]
- ProjectB/Subproject:
  - members: []                 # nothing explicit, but membership cascades

But, if you add another layer of indirection, and it no longer works: thcipriani CANNOT push to ProjectC/Subproject:

- ProjectA:
  - members: [thcipriani:owner]
- ProjectB:
  - members: [ProjectA:owner]
- ProjectC:
  - members: [ProjectB:owner]
- ProjectC/Subproject:
  - members: []                 # nothing explicit, but membership cascades

What's happening here

This doesn't work: I would not be able to push to ProjectB (nor would I expect to):

- ProjectA:
  - members: []
- ProjectA/Subproject:
  - members: [thcipriani:owner]
- ProjectB:
  - members: [ProjectA:owner]

I'd expect to fix this by adding ProjectA/Subproject as a member of ProjectA

But that creates a confusing version of the Simple Example above (where I try to push to ProjectC/Subproject).

I am not able to push to ProjectB/Subproject because there are two layers of indirection involved.

- ProjectA:
  - members: [ProjectA/Subproject]
- ProjectA/Subproject:
  - members: [thcipriani:owner]
- ProjectB:
  - members: [ProjectA:owner]
- ProjectB/Subproject
  - members: []

Likewise, this fails (due to two levels of indirection):

- ProjectA:
  - members: [ProjectA/Subproject]
- ProjectA/Subproject:
  - members: [thcipriani:owner]
- ProjectB/Subproject
  - members: [ProjectA:owner]

Clearer explanation on the upstream task by Alex Pooley

This is the core problem we discussed on our call where we handle shared groups for direct members only, but not shared groups of shared groups. E.g.

User1 -- member of --> GroupA
GroupA -- shared into --> GroupB
GroupB -- shared into --> GroupC

Currently, User1 is only a member of GroupA and GroupB, but not GroupC.
This issue is requesting that User1 become a member of GroupC. It makes sense that if permissions flow through one level then they flow through deeper levels.