sonar-scanner-msbuild icon indicating copy to clipboard operation
sonar-scanner-msbuild copied to clipboard

SonarScanner.MSBuild.dll should not require manual CHMOD

Open Evangelink opened this issue 6 years ago • 15 comments

Description

When running the netcore-app scanner on linux dotnet SonarScanner.MSBuild.dll begin /k:<KEY> we end-up with a missing permission issue. This is because the dll needs to receive a CHMOD.

This shouldn't be required.

Evangelink avatar Apr 27 '18 14:04 Evangelink

Cannot reproduce this one, even on Julien Henry's machine. I tried with:

  • Built-in Linux Subsystem on Windows (Ubuntu 16)
  • Clean Docker image (Ubuntu 18)
  • JH's machine (Debian or Fedora?)

I suggest closing unless @Evangelink wants to try something different.

valhristov avatar May 28 '18 07:05 valhristov

This is not the dll, but the shell scripts of the scanner-cli that need to be chmod +x.

henryju avatar May 28 '18 09:05 henryju

@henryju Do you think it needs to be done on our side? Or can it be done directly on your side (i.e. scanner cli) when you package it?

Evangelink avatar May 28 '18 11:05 Evangelink

@henryju if it is the shell scripts, then we have another ticket #450

valhristov avatar May 28 '18 11:05 valhristov

@Evangelink The scanner-cli packaging is fine. The permission is probably lost when it in unzipped, and then zipped again into to scanner-msbuild distribution.

henryju avatar May 28 '18 13:05 henryju

@henryju Thx for the info

Evangelink avatar May 28 '18 13:05 Evangelink

Reopened after @dmitry-golovinov-sonarsource findings: "I've found that we ship scanner for msbuild with linux batch file (sonar-scanner-msbuild\sonar-scanner-4.6.2.2472\bin\sonar-scanner) that has no executable attribute on it. That makes it impossible to run under linux environment without explicit fix chmod +x of that file. Moreover, this issue is hard to find, since this file doesn't get launched directly, but from the code of SonarScanner.MSBuild.dll assembly and the exception we see is not really explanatory."

The error that appears on Linux:

Unhandled exception. System.ComponentModel.Win32Exception (13): Permission denied at System.Diagnostics.Process.ForkAndExecProcess(String filename, String[] argv, String[] envp, String cwd, Boolean redirectStdin, Boolean redirectStdout, Boolean redirectStderr, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec) at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start() at SonarScanner.MSBuild.Common.ProcessRunner.Execute(ProcessRunnerArguments runnerArgs) at SonarScanner.MSBuild.Shim.SonarScannerWrapper.ExecuteJavaRunner(AnalysisConfig config, IEnumerable1 userCmdLineArguments, ILogger logger, String exeFileName, String propertiesFileName, IProcessRunner runner) at SonarScanner.MSBuild.Shim.SonarScannerWrapper.InternalExecute(AnalysisConfig config, IEnumerable1 userCmdLineArguments, ILogger logger, String fullPropertiesFilePath) at SonarScanner.MSBuild.Shim.SonarScannerWrapper.Execute(AnalysisConfig config, IEnumerable`1 userCmdLineArguments, String propertiesFilePath) at SonarScanner.MSBuild.PostProcessor.MSBuildPostProcessor.InvokeSonarScanner(IAnalysisPropertyProvider cmdLineArgs, AnalysisConfig config, String propertiesFilePath) at SonarScanner.MSBuild.PostProcessor.MSBuildPostProcessor.Execute(String[] args, AnalysisConfig config, ITeamBuildSettings settings) at SonarScanner.MSBuild.BootstrapperClass.PostProcess() at SonarScanner.MSBuild.BootstrapperClass.Execute() at SonarScanner.MSBuild.Program.Execute(String[] args, ILogger logger) at SonarScanner.MSBuild.Program.Execute(String[] args) at SonarScanner.MSBuild.Program.Main(String[] args) at SonarScanner.MSBuild.Program.<Main>(String[] args) 11:50:46.996 INFO Stop server

it can be helpfull - you can add file .targets in build folder something like https://github.com/AdaskoTheBeAsT/SqlPackage/blob/main/build/nuspecs/AdaskoTheBeAsT.SqlPackage.native.linux.x64/build/AdaskoTheBeAsT.SqlPackage.native.linux.x64.targets

how to get os it is here https://github.com/AdaskoTheBeAsT/SqlPackage/blob/main/build/nuspecs/AdaskoTheBeAsT.SqlPackage.native/build/AdaskoTheBeAsT.SqlPackage.native.props

you can combine that to one .targets file and execute chmod only for given platform

offtopic for macos chmod looks little different https://github.com/AdaskoTheBeAsT/SqlPackage/blob/main/build/nuspecs/AdaskoTheBeAsT.SqlPackage.native.osx.x64/build/AdaskoTheBeAsT.SqlPackage.native.osx.x64.targets

AdaskoTheBeAsT avatar Nov 22 '21 17:11 AdaskoTheBeAsT

Hi @AdaskoTheBeAsT, thank you for the hint. If I understand it correctly, this approach still requires the build and packaging to run on a Linux box, right?

Hi @pavel-mikula-sonarsource - build and packaging is not required for .net based libs/apps - only for native ones - as I only had sample which uses native app I pasted this one

AdaskoTheBeAsT avatar Nov 23 '21 08:11 AdaskoTheBeAsT

Question for us to investigate: is the Azure DevOps extension affected when running on Linux?

The WHY and the WHAT are clear - manual chmod should not be necessary on Unix systems.

For the HOW, some possible solutions:

  1. Add a native specific target to chmod +x the executable when installing on linux boxes (see here, we can do it in the SQ Target).

Problem: it will do it every time, which is not necessary. But this won't have a functional impact. Problem: might have problems with user permissions - it depends on what user owns the scanner installation folder vs what user executes the build.

  1. Call the CLI directly (without the script) - as suggested in #450.

the scripts are %SCANNER_INSTALLATION%\sonar-scanner-{SCANNER_CLI_VERSION}\bin

Problem: HOW?


Pragmatically - option 1 (it's easier). Downside - only if the chmod +x won't work.

first investigate if we can fix the root cause : permission not getting lost when unzip + zip

Reopening. We reverted it for bugfix release 5.7.1.

Just as a reminder, for when this ticket is picked up:

This is an issue in macOS as well (typically linux uses bash, macOS uses zsh, but both are Unix-like operatin systems). There was some investigation done internally and more details can be found on this dogfood thread (internal link).