Single file executable extraction path not writable when setuid bit is used

[bobvandevijver]

Description

When you have a single file dotnet core application, it will extract itself to a directory. The location can be influenced with the DOTNET_BUNDLE_EXTRACT_BASE_DIR, but by default it seems to use /home/<user>/.net/<app>.

However, when the setuid bit has been set to execute the application as another user, the extraction path user is not adjusted accordingly. This causes the execution of the application to fail, as it cannot create the directory due to insufficient rights.

Reproduction Steps

Build a self-contained "Hello World" app, with the following properties:

<Project Sdk="Microsoft.NET.Sdk">
    <Import Project="..\default.props" />
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.1</TargetFramework>
        <PublishSingleFile>true</PublishSingleFile>
        <SelfContained>true</SelfContained>
        <RuntimeIdentifier>linux-musl-x64</RuntimeIdentifier>
        <InvariantGlobalization>true</InvariantGlobalization>
    </PropertyGroup>
    <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
        <DebugType>none</DebugType>
        <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    </PropertyGroup>
</Project>

Compile with dotnet publish -c Release <your-app> -r <your-rid>

Expected behavior

I expect that the directory used for extracting is based on the user after the setuid bit has been "applied", and not the user that has initially started the execution.

In the example under "Actual behaviour" the extraction should happen in /home/appuser/.net/App/ as the user running the application is appuser due to the setuid bit, and not the user (bobv) that is initially invoking the account.

Actual behavior

XPS15-BOB:/opt/nis$ ls -la
total 78220
drwxr-xr-x    2 bobv     root          4096 Nov 11 09:47 .
drwxr-xr-x    3 root     root          4096 Nov 11 09:45 ..
-rwsr-xr-x    1 appuser      bobv      80085655 Nov 11 09:45 App
XPS15-BOB:/opt/nis$ ./App
Failure processing application bundle.
Failed to create directory [/home/bobv/.net/App/] for extracting bundled files
A fatal error was encountered. Could not extract contents of the bundle

Regression?

No response

Known Workarounds

Set the DOTNET_BUNDLE_EXTRACT_BASE_DIR environment variable to a path that can be written by the user actually running the app.

Configuration

I'm using dotnet 6.0.100 to publish the file, which targets netcoreapp3.1. I cannot upgrade because I need to support RHEL6, as the lab equipment this needs to run on cannot be upgraded.

I have confirmed this using the following rids:

• rhel.6-x64 (yes, I know, nothing I can do about this unfortunately)
• rhel.7-x64
• linux-musl-x64
• linux-x64 (possibly, couldn't test this completely as it triggers a BSOD on my WSL1 Debian)

Other information

This method retrieves the directory:

runtime/src/native/corehost/bundle/extractor.cpp

Line 38 in 6f5de0b

if (!pal::get_default_bundle_extraction_base_dir(m_extraction_dir))

Here is uses the HOME env var, which is indeed the wrong home directory when the setuid bit has been set:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Line 342 in c88c88a

if (pal::getenv(_X("HOME"), &directory))

Although I'm not sure why the read/write check passes (or at least, I think it is).

Tagging subscribers to this area: @agocke, @vitek-karas, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

When you have a single file dotnet core application, it will extract itself to a directory. The location can be influenced with the DOTNET_BUNDLE_EXTRACT_BASE_DIR, but by default it seems to use /home/<user>/.net/<app>.

However, when the setuid bit has been set to execute the application as another user, the extraction path user is not adjusted accordingly. This causes the execution of the application to fail, as it cannot create the directory due to insufficient rights.

Reproduction Steps

Build a self-contained "Hello World" app, with the following properties:

<Project Sdk="Microsoft.NET.Sdk">
    <Import Project="..\default.props" />
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.1</TargetFramework>
        <PublishSingleFile>true</PublishSingleFile>
        <SelfContained>true</SelfContained>
        <RuntimeIdentifier>linux-musl-x64</RuntimeIdentifier>
        <InvariantGlobalization>true</InvariantGlobalization>
    </PropertyGroup>
    <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
        <DebugType>none</DebugType>
        <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    </PropertyGroup>
</Project>

Compile with dotnet publish -c Release <your-app> -r <your-rid>

Expected behavior

I expect that the directory used for extracting is based on the user after the setuid bit has been "applied", and not the user that has initially started the execution.

In the example under "Actual behaviour" the extraction should happen in /home/appuser/.net/App/ as the user running the application is appuser due to the setuid bit, and not the user (bobv) that is initially invoking the account.

Actual behavior

XPS15-BOB:/opt/nis$ ls -la
total 78220
drwxr-xr-x    2 bobv     root          4096 Nov 11 09:47 .
drwxr-xr-x    3 root     root          4096 Nov 11 09:45 ..
-rwsr-xr-x    1 appuser      bobv      80085655 Nov 11 09:45 App
XPS15-BOB:/opt/nis$ ./App
Failure processing application bundle.
Failed to create directory [/home/bobv/.net/App/] for extracting bundled files
A fatal error was encountered. Could not extract contents of the bundle

Regression?

No response

Known Workarounds

Set the DOTNET_BUNDLE_EXTRACT_BASE_DIR environment variable to a path that can be written by the user actually running the app.

Configuration

I'm using dotnet 6.0.100 to publish the file, which targets netcoreapp3.1. I cannot upgrade because I need to support RHEL6, as the lab equipment this needs to run on cannot be upgraded.

I have confirmed this using the following rids:

• rhel.6-x64 (yes, I know, nothing I can do about this unfortunately)
• rhel.7-x64
• linux-musl-x64
• linux-x64 (possibly, couldn't test this completely as it triggers a BSOD on my WSL1 Debian)

Other information

This method retrieves the directory:

runtime/src/native/corehost/bundle/extractor.cpp

Line 38 in 6f5de0b

if (!pal::get_default_bundle_extraction_base_dir(m_extraction_dir))

Here is uses the HOME env var, which is indeed the wrong home directory when the setuid bit has been set:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Line 342 in c88c88a

if (pal::getenv(_X("HOME"), &directory))

Although I'm not sure why the read/write check passes (or at least, I think it is).

Author:	bobvandevijver
Assignees:	-
Labels:	area-Single-File, untriaged
Milestone:	-

[vitek-karas]

You can enable tracing:

export COREHOST_TRACE=1
export COREHOST_TRACEFILE=host.txt

Repro the failure and see host.txt in current directory. It should have more details on why it picked a certain folder.
Since the app is targeting 3.1 it should be using the .NET Core 3.1 host. So the code for that is actually here: https://github.com/dotnet/core-setup/blob/29be638bf4b745d1356a8dc45846ca46deda955a/src/corehost/common/pal.unix.cpp#L275-L310

Recently there's an added capability to read the "home" from the getpwuid function if HOME is not defined. But that doesn't seem to be the case here. Maybe we could improve on this and if the HOME exists and it's not writable, use the one from getpwuid...

[bobvandevijver]

Here's the output!

Tracing enabled @ Thu Nov 11 11:10:23 2021 UTC
--- Invoked apphost [version: 3.1.21, commit hash: df8abc0f7ea6a8add9cdb23adc8b18673a329df8] main = {
./App
}
The managed DLL bound to this executable is: 'App.dll'
Files embedded within the bundled will be extracted to [/home/bobv/.net/App/OSmwyoj0Foxb46lYJfUDpkSHLcKSsrE=] directory
Failure processing application bundle.
Failed to create directory [/home/bobv/.net/App/] for extracting bundled files
A fatal error was encountered. Could not extract contents of the bundle

[vitek-karas]

I think that matches what you described in your analysis of the problem. I don't know either why the read/write check on HOME seems to succeed though.