Open bobvandevijver opened 2 years ago
Tagging subscribers to this area: @agocke, @vitek-karas, @vsadov See info in area-owners.md if you want to be subscribed.
Author: | bobvandevijver |
---|---|
Assignees: | - |
Labels: | `area-Single-File`, `untriaged` |
Milestone: | - |
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
...
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
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.
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:
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 isappuser
due to thesetuid
bit, and not the user (bobv
) that is initially invoking the account.Actual behavior
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:
Other information
This method retrieves the directory:
https://github.com/dotnet/runtime/blob/6f5de0b2b979a70e6fe36904d0d4f087c32f9c7e/src/native/corehost/bundle/extractor.cpp#L38
Here is uses the
HOME
env var, which is indeed the wrong home directory when thesetuid
bit has been set:https://github.com/dotnet/runtime/blob/c88c88a5f07325a70322cfc056949e8d52e4a04f/src/native/corehost/hostmisc/pal.unix.cpp#L342
Although I'm not sure why the read/write check passes (or at least, I think it is).