Wrong inheritance group permission with gitlab group sync alm enabled

SonarQube Server / Community Build
, ,
1

Hi all,
i’m new here, so pls be patient if i do something wrong.

ALM GitLab “Synchronize user groups” sets wrong group permissions to Sonar Users that are not inside any gitlab groups, for example users having only developer role directly inside gitlab projects.

  • versions used: SonarQube 8.5 CE

  • error observed: Wrong group permissions for Sonar Users not inside GitLab groups.

  • steps to reproduce

    Assume we have GitLab ALM enabled with “Syncronize user groups” enabled too.

    1. create gitlab user (eg: user1)
    2. create gitlab group (eg: groupA)
    3. inside groupA create new project (eg: groupA/projectA)
    4. inside groupA create new subgroup (eg: groupA/groupA1)
    5. inside groupA1 create new project (eg: groupA/groupA1/projectA1)
    6. inside groupA1 create new project (eg: groupA/groupA1/projectA2)
    7. assign developer role to user1 inside projectA1 only

    Now you should have

    groupA            <- with no user1 permissions
|- projectA       <- with no user1 permissions
|- groupA1        <- with no user1 permissions
   |- projectA1   <- with user1 developer role
   |- projectA2   <- with no user1 permissions
    1. In SonarQube create group groupA and group groupA/groupA1 (as explained here)
    2. sonar-scanner projectA and assign project permission (browse sufficient) to groupA
    3. sonar-scanner projectA1 and assign project permission (browse sufficient) to groupA/groupA1
    4. sonar-scanner projectA2 and assign project permission (browse sufficient) to groupA/groupA1

    Now, when user1 loggin in SonarQube using GitLab auth, sonar will auto-assign user1 to both groupA and groupA/groupA1 even if user1 does not belong to any group in GitLab.

    As a consequence, user1 will be able to see all scanned projects assigned in both groups:
    projectA, projectA1 and projectA2.

  • potential workaround
    not found atm

I can imagine that sonar plugin will call gitlab /api/ to read where user1 can access or not, and maybe this is complex to resolve, but this issue could be a little security risk for some kind of organizations.

Thanks however for all help u can do, and excuse me if I haven’t been clear enough, i’m not native english speaker :slight_smile:

Bye and thanks for SonarQube, it’s really awesome! :muscle:

3

Hi Andrea and welcome to our community :slight_smile:
You message is perfect, thanks for the detailed steps to reproduce.
I pinged an expert on this topic to see if we have a workaround about this.
Kind regards,
Christophe

4

Hi @Christophe_Havard,
do you have any news about this Sonar bug ?

Kind regards, and thanks for your support,
Andrea.