Permission template errors / UI/UX of errors

In SonarQube Enterprise, you can define Permission Templates that are regex-based.
However, the reg-exes should not overlap each other, because then SQE doesn’t know which permission template to apply.

This is basically a bug-report, that describes poor UX and the need to enable debug to find out what is actually going on.

This report is basing on SQE version 8.9.5 and maven sonar-scanner:3.9.1.2184.

Problem #1:
If there are overlapping regexes in permission templates, the maven sonar:sonar fails with a cryptic error:

Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar (default-cli) on project xxxx: Failed to upload report - An error has occurred. Please contact your administrator

Checking the logs (with loglevel INFO) on the server itself does not show anything. Only when the log level is changed to DEBUG, it suddenly shows:

022.04.05 21:39:56 ERROR web[AX8b3DN5xtAzZeqHHTj8][o.s.s.w.WebServiceEngine] Fail to process request …
java.lang.IllegalStateException: The “…” key matches multiple permission templates: “PT1”, “PT2”. A system administrator must update these templates so that only one of them matches the key.

  • This error should be visible as ERROR in the sonar:sonar web.log on INFO level but for some reason it is not.
  • This error should be also passed to the sonar scanner so that one do not have to get into server logs to see what is the problem.

Problem #2 (root cause of above):
It should not be possible to create permission templates with overlapping regexes.

Happy to provide more details if needed.

Hello @warden
thanks for your report.
About #1.
SONAR-15579 improvement is available in version 9.2.
You’ll get a fully explicit Error message if you create the project from SonarQube UI or the scanner (not recommended for most large SonarQube instances).

java.lang.IllegalStateException: Failed to upload report: The "testCollision" key matches multiple permission templates: "collision", "Template for test projects". A system administrator must update these templates so that only one of them matches the key.

image

About #2
Interesting idea. However:

  • That is not likely to help as much as #1
  • Having actual regex collisions will mostly depend on the project key conventions
  • having to set mutually exclusive regex might lead to much more complex ones.

Thanks for a quick reply Sylvain!

It’s nice to hear 9.2 has some improvements in this area. Let me comment on #2 though, since the UI error (hopefully also visible in the scanner) is only a “result” of a misconfiguration of the regexes.
I mean, it does not actually resolve the root cause of the issue.

Re #2, I disagree as this is actually the root cause of the issue.
Imagine a large intstance (like we have) where we have multiple admins managing their own Permission Templates. One administrator might be changing one big-project’s related regex and even be unaware that if it conflicts with other one, it will ultimately break the scans (and the related CI pipelines) that were working before.

By a specific example:
Imagine having the following:
Permission Template 1 with regex: com.domain.project1.*
Permission Template 2 with regex: com.domain.project2.*

The builds and scans are working fine, everyone is happy.

Now, another project is created and the admin unwillingly (because he would have to manually check all of them) creates a PT3 with regex: com.domain.*

Now suddenly project1, project2 and project3 scans stop working because the templates are in conflict.

PS. What do you mean by “or the scanner (not recommended for most large SonarQube instances)” ?
Do you mean that projects should be pre-created before the scan?
That doesn’t sound right for maven scanner because of all of the autodetection features (i.e. projectKey is derived from groupId etc.)

Additionally contributing are those unresolved issues:
https://jira.sonarsource.com/browse/SONAR-12165
https://jira.sonarsource.com/browse/SONAR-12129

Hi @warden
A project permission template is applied only once to a project: when it is created.
A conflict on a new project will only prevent this new project from being analyzed; the others are safe: no existing project analysis is impacted.

Allowing some CI stored tokens to create projects is a known way to lose control of projects keys.
Yes, on maven, a default project key is generated. This is a historical feature, not fitting for all organizations, and you can always configure your project key in the pom.xml or from the scanner command line.

And improvements are usually not backported to the LTS (it only gets security and essential bug fixes).
On 8.9 LTS, you have a bonus with UI projects creation: the possibility to set the main branch name before the first analysis.

Hi @Sylvain_Combe,

From your response I understand that the official recommendation (for large scale) is that:

  • the user with Execute Analysis permission that is used in the CI should NOT have create project permissions
  • that the projects should be pre-created by a real user first before the first scan.

Could you refer some official part of docs that we missed that is mentioning this good practice?

For the “bonus in the UI”, yes, I’m aware, but that is again another manual step that needs to be performed.

The goal however is to automate project setup in large-scale with CI system - we’re not loosing the control of project keys, because the project creation is done via API or maven scanner result - and permissions are controlled on the Permission Templates level - hence the original report that it’s easy to actually loose track of regexes in a big installation with multiple permission templates without any warning about overlaps and different admins handling different projects.

Thanks a lot for the recommendation though, we’ll take it into consideration.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.