Prevent anyone EA permission for project

permissions

(Nikolay Angelov) #1

Hello,

We have sonar 6.7.3 and in Global permission for Anyone group is checked for EA permission. Even that I want to prevent my project as a “project admin” to be executed analysis only by authenticated users but not anonymous. Is there a way to achieve that?


(Colin Mueller) #2

Nikolay,

I like the idea of an “Authenticated Users” group existing by default (nudges SonarSource)

As a workaround, you could have an administrator (perhaps that’s yourself) create a similarly-named group and add all existing users, and use that for your global/project level permissions.

Colin


(Nicolas Bontoux) #3

Hey Guys,

To me this is the very definition of the (built-in, and existing since a while) sonar-users group (Any new users created will automatically join this group).


(Colin Mueller) #4

Nico,

I forgot about sonar-users because I believe when you use an external identity provider like LDAP, that group membership gets wiped away when the user logs in and groups are fetched from the identity provider.

Colin


(Nikolay Angelov) #5

Hello Nico, Colin,

Thank you for your advices!

Unfortunately it is not so easy. I will explain my current status, what I want to achieve and how to solve it.

Currently we have a Sonar server with around 100 projects. They also have added LDAP users as project admins (not use local sonar users). In Global Permissions group “Anyone” has set EA flag. In Default Permission template only “Project creator” can execute analysis. This configuration give EA permission to “Anonymous user” and we cannot prevent that.
We want project admin to able to prevent anonymous user to execute analysis.
On other hand we cannot just stop anonymous user executions for all projects because some of them run without user and it should continue as it is.
The solution is to remove EA flag in Global Permission group “Anyone”. Also in Default Permission template to add “anyone” group and EA flag to be checked.
This configuration means that every new project will be created with “anyone” group with checked EA and project admins if want can uncheck the flat. It works as we want for the new projects. The problem is how to make it for existing ones. The bulk update of project template will overwrite the current given LDAP user permissions so it is not solution.
The only fix I found is to write a script who will edit project permissions in all existing project and add “anyone” group with checked EA flag. After that I can change my current Global permissions and Default permission template.
It would be good if it is possible to have a check box in bulk update template update which give choice to overwrite only the affected groups.

Regards,
Nikolay


(Nicolas Bontoux) #6

Hi guys,

I doubt the behaviour you indicate here. sonar-users really is a special built-in group. So even if LDAP Group Mapping is effective, any logged-in user will still virtually belong to sonar-users (even though sonar-users is not defined in LDAP). Just verified this on 6.7.x LTS and 7.2, sonar-users shows up under My Account after logging-in.

Why can’t you prevent that ? SonarQube admins have full control over permissions given to Anyone, and it would definitely make sense that Anyone is not allowed to run an analysis.

This doesn’t seem like a strong enough reason on the long term. Can pose security concerns, and also demeans any traceability of what’s going on.

I would suggest to not allow anyone by default, and let project admins override this at their own risk.


(Nikolay Angelov) #7

Hi Nico,

When EA is checked in Global Permissions on project level Anyone group has no checked boxes and cannot be unchecked. Admins cannot overwrite global permissions on project level. It would be good if it is possible.


(Colin Mueller) #8

Nico,

My mistake! But I’ll turn that mistake into some UX feedback – it’s confusing that of the two groups that exist by default on a SonarQube instance, one acts differently than the other (sonar-administrator membership being wiped away when logging in with an external identity provider that sends group info).

Thanks,

Colin