Excessive permissions on /tmp/VBCSCompiler

[danmoseley]

Repro.

1. Create Ubuntu 20.04 WSL2 instance.
2. Install .NET 6.0 SDK per the online instructions.
3. Create a project with dotnet new console

Result:

root@danmoseL:~/proj/2# ls -alF /tmp | grep VBCS
drwxr-xr-x  3 root root 4096 Jun 14 08:16 VBCSCompiler/
root@danmoseL:~/proj/2# stat -c '%n %a' /tmp/VBCSCompiler/
/tmp/VBCSCompiler/ 755

Here the VBCSCompiler access mask is 0755. Can this be 0700?

Similarly for some of the contents, eg

root@danmoseL:~/proj/2# stat -c '%n %a' /tmp/VBCSCompiler/AnalyzerAssemblyLoader/acd1a71f212448e98aedfa5820116735/4/de/Microsoft.CodeAnalysis.CodeStyle.resources.dll
/tmp/VBCSCompiler/AnalyzerAssemblyLoader/acd1a71f212448e98aedfa5820116735/4/de/Microsoft.CodeAnalysis.CodeStyle.resources.dll 744

(Context: we discovered we are inconsistent with perms we apply on files and directories we write to /tmp. @agocke made a first start at writing down guidance and I'm opening bugs. I'm assuming we'll discover places we need to adjust the guidance.)

[jcouv]

@danmoseley I'm a bit confused. Which file or folder has incorrect permissions?

When I tried this, I created a folder (issue-61900) and ran dotnet new console in it. That yields .cs and a .csproj files (with permission 644) and an obj folder with various 644 files.

[danmoseley]

Do you see /tmp/VBCSCompiler/ @jcouv ? It seems to come and go. The focus is on /tmp/ because on Unix (unless you set TMPDIR) it is shared between users of the machine, whereas on Windows it is not. That's why perms on anything we put there are potentially interesting, and we're inconsistent with them, possibly partially because until this release we haven't had an API to set them. It's coming but meantime you'd have to pinvoke to chmod.

Conversely perms of anything in your ~/issue-61900 (ie your home) are less interesting, since as I understand it (and I am very much learning how this works) by default other users can't access it.

[jcouv]

Thanks for clarifying @danmoseley :-)
When I saw /tmp/VBCSCompiler in your repro steps, I assumed it was your working folder (for dotnet new console). I have no idea what's creating that folder, but will dig to find out.

[danmoseley]

Thanks. Yes, as I understand it /tmp (or $TMPDIR if set -- Path.GetTempPath() will get it right) is the right place even for stuff that's specific to a user, but as noted, the onus becomes on us to ensure that it's only readable by that user.

https://github.com/dotnet/runtime/blob/main/docs/design/security/unix-tmp.md

[jaredpar]

@danmoseley why did you assign this to the roslyn repo? That directory is created as an implementation detail of the NamedPipeServerStream implementation on Unix. The roslyn code doesn't create or manipulate this directly.

[danmoseley]

Hmm, I didn't realize that. (Wouldn't it have a CoreFXPipe_ prefix though? https://github.com/dotnet/runtime/blob/7e213b3816d60686169b97969016acd21d62802b/src/libraries/System.IO.Pipes/src/System/IO/Pipes/PipeStream.Unix.cs#L33)

Feel free to transfer back if it's not Roslyn responsible for this.

[agocke]

Roslyn specifies the prefix, but I'm not sure who's responsible for the permissions: https://sourceroslyn.io/#VBCSCompiler/NamedPipeUtil.cs,24

[agocke]

@jaredpar looks like there's more than just the named pipe stuff in here though. Idk what it is (what's the AnalyzerAssemblyLoader directory?)

[jaredpar]

Idk what it is (what's the AnalyzerAssemblyLoader directory?)

That is the directory we copy analzyer / generator assemblies to in order to do fake shadow loading.

[jaredpar]

compiler no longer uses temp directories on Linux as we use LoadFromStream instead.