Docker versions > sonar-scanner-cli:5.0.1 stop working when running as user uid != 1000

SonarQube Cloud
,
1

Docker versions > sonar-scanner-cli:5.0.1 stop working when running as user uid != 1000.

Fails with Access Denied exceptions due to directories no longer having chmod 777 permissions on the following directories in the newer container image versions preventing upgrading to the newer images:

  • /tmp/.scannerwork/
  • /opt/sonar-scanner/.sonar

Affected versions: >= sonar-scanner-cli:10.0.0.1370_5.0.1, 10, 11

We use sonar-scanner-cli in a CI/CD context where we mount the workspace, and other directories from the host into the container, so requiring us to run that CI/CD build with uid=1000 causes file ownership issues on our CI/CD.

Suggested fix, is to make these write directories used by sonar-scanner-cli to in the container have chmod 777 permissions like before in sonar-scanner-cli:5.0.1.

Reproducing steps:

docker run --rm -u 999:999 -e SONAR_TOKEN=$SONAR_TOKEN sonarsource/sonar-scanner-cli:11.4.0.2044_7.2.0 sonar-scanner

16:35:09.012 INFO  Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
16:35:09.014 INFO  Project root configuration file: NONE
16:35:09.022 INFO  SonarScanner CLI 7.2.0.5079
16:35:09.024 INFO  Linux 6.6.87.2-microsoft-standard-WSL2 amd64
16:35:09.049 INFO  EXECUTION FAILURE
16:35:09.049 INFO  Total time: 0.040s
16:35:09.050 ERROR Error during SonarScanner CLI execution
java.lang.IllegalStateException: Unable to create directory: /opt/sonar-scanner/.sonar/cache
        at org.sonarsource.scanner.downloadcache.DownloadCache.mkdirs(DownloadCache.java:141)
        at org.sonarsource.scanner.downloadcache.DownloadCache.<init>(DownloadCache.java:48)
        at org.sonarsource.scanner.downloadcache.DownloadCache.<init>(DownloadCache.java:53)
        at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:138)
        at org.sonarsource.scanner.cli.Main.analyze(Main.java:76)
        at org.sonarsource.scanner.cli.Main.main(Main.java:64)
Caused by: java.nio.file.AccessDeniedException: /opt/sonar-scanner/.sonar/cache
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
        at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:397)
        at java.base/java.nio.file.Files.createDirectory(Files.java:700)
        at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:807)
        at java.base/java.nio.file.Files.createDirectories(Files.java:793)
        at org.sonarsource.scanner.downloadcache.DownloadCache.mkdirs(DownloadCache.java:139)
        ... 5 common frames omitted
16:35:09.051 ERROR 
16:35:09.051 ERROR Re-run SonarScanner CLI using the -X switch to enable full debug logging.

This otherwise worked with 5.0.1 which does have these directories with chmod 777. It says execution failure but that’s just sonar server reachability, past the point of this bug.

ocker run --rm -u 999:999 -e SONAR_TOKEN=$SONAR_TOKEN sonarsource/sonar-scanner-cli:5.0.1 sonar-scanner
INFO: Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
INFO: Project root configuration file: NONE
INFO: SonarScanner 5.0.1.3006
INFO: Java 17.0.10 Alpine (64-bit)
INFO: Linux 6.6.87.2-microsoft-standard-WSL2 amd64
INFO: User cache: /opt/sonar-scanner/.sonar/cache
ERROR: SonarQube server [http://localhost:9000] can not be reached
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 0.329s
INFO: Final Memory: 4M/20M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarScanner execution
Unable To Launch Sonar Scanner CLI 10.0.0.1370_5.0.1 Container In Jenkins 2.462.3
Error when starting Sonar analysis
2

I want to upgrade due to the failures from this image version being bundled with node-v18 (from last week), and now the warning to move to a newer node version in more recent images but the newer images don’t work the way they used to when needing to run with a different uid.

3

Hi,

Welcome to the community!

SonarScanner CLI 5.0.1 is more than two years old at this point. Can you try this with the latest version, please?

 
Thx,
Ann

4

Hi Ann,

Thanks for the reply, I did. The reproduction steps use docker image sonarsource/sonar-scanner-cli:11.4.0.2044_7.2.0. This is a bug report of that new image, and all images in between the latest and 5.0.1 have this problem. It is preventing us from upgrading to recent versions.

Much appreciated.

5

Hey there.

This was, I believe, quite intentional. SCANDOCKER-2

And, you should be able to go back to the previous behavior by running docker --user root. Is that feasible for you?

6

It is not feasible. I agree with running as root is an anti-pattern. We don’t, and we didn’t need to before. We run it as the UID that our CI/CD platform uses (which is not uid=1000).

I think sonar could use better intentional support for the image to be designed to run as any UID. Advice is given in these forms for image use to set $SONAR_HOME and bind mount a directories to enable preservation of the $SONAR_HOME/.cache directory between CI/CD builds. If we do this, I want files written in that directory to be owned by my UID on the host, not the sonar image’s uid=1000 (and certainly not root). That advice is at odds with the newer images.

The CLI also requires write permission to /tmp/.scannerwork/, which isn’t documented to be overridable with an ENV VAR which is another barrier to using our desired UID. So clever not documented workarounds are needed. We shouldn’t have to do that as an image user.

The intentional changes made in newer versions of the cli image broke CI/CD use cases that I think are useful. Now I have to do work to make & maintain my own image to address the gap.

1 Like
7

this comment-thread in the quoted issue is interesting. maybe it was more of an accidental intentionality? :slight_smile:

9

Let me ping the team.

10

Hi Colin, any updates from the team? Thanks.

11

I’m sorry, @huberts, not yet.