-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when trying to run non-elevated from an elevate process #37129
Comments
Tagging subscribers to this area: @eiriktsarpalis |
The .NET Framework and .NET Core implementations of I wonder if dotnet/coreclr#28019 is related? But that fix was present beginning in 3.1.3 (I verified) and the above is 3.1.4 @stephentoub anything occur to you? |
@enricogior is it possible to try some other .NET Core versions? Specifically 3.1.2 or earlier. Any 5.0 preview might be an interesting datapoint as well. |
Or perhaps @ericstj has a theory. |
WpfDllVerifier that is calling
Does it work for .Net Framework app that just calls |
The most likely explanation for this behavior is that the techniques to launch non-elevated process from elevated one strip the rights for the process to inspect itself. An experiment with an app that calls |
Thank you! I did not know that the Process.Modules call was new. |
@danmosemsft
I tried 3.1.0 and got the same problem.
Is there any other step required? |
@jkotas |
@enricogior can you please try the experiment @jkotas suggested above - create a.NET Framework console app and paste in |
Agree with @jkotas assessment. In @oldnewthing's blog you see the technique you are using is copying permissions from some other process. You need to make sure the process you choose to copy has all the permissions that match an unelevated process. Likely Explorer doesn't have |
@danmosemsft @ericstj |
I didn't dig deeper into your second method. It seems As an aside, I noticed a possible optimization here that could avoid this codepath in Process calling OpenProcess. It looks like |
Perhaps the way forward @enricogior is to create a little Hello World style repro using pure native Win32 that simply calls Maybe we could work around this in our code, but that might change product behavior, and more importantly doesn't help most of your customers since they want to launch other apps and older versions of .NET Core which may still hit this |
@ericstj @danmosemsft |
@enricogior any progress on this? |
Hi @adamsitnik |
The call to The issue should be fixed. @enricogior please feel free to reopen if it does not work for .NET 5 WPF for you. |
@adamsitnik |
Description
PowerToys needs to start a .NET Core application with non-elevated privileges from an elevated process.
We tried two different approaches, they both resulted in this crash report:
First approch: start the application as suggested in this Raymond Chen's article
https://devblogs.microsoft.com/oldnewthing/20190425-00/?p=102443
It works for Win32 apps and for .Net Framework apps, it causes the crash when tested with the two .NET Core apps we have in PowerToys.
Second approach: use an intermediate process and drop the elevation in that process before starting the .NET Core app. It works when using
SDDL_ML_MEDIUM
but crashes when usingSDDL_ML_MEDIUM_PLUS
, in our scenarioSDDL_ML_MEDIUM
causes other issues so we can't use it.https://github.com/microsoft/PowerToys/blob/e75a74565b8f7eb208af52dbb10632f943b66d21/src/common/common.cpp#L396-L421
Configuration
.NET Core 3.1.4
Windows 10 1909
x64
Regression?
Other information
I can provide a branch with the changes that cause the crash, if needed.
The text was updated successfully, but these errors were encountered: