microsoft
PerfView should run the debugging application as a normal user and not as an elevated (admin) user
Hello
When we run an application with PerfView (clicking on "Run a command", or by the menus "Collect" / "Run" (Alt-R), or by command line "run"), PerfView elevates itself then run the application as elevated too. That is a security threat, and it prevents debugging Window Store applications (they fail running, see https://social.msdn.microsoft.com/Forums/en-US/41170c0f-405c-45d8-abcd-b7a376c70c48/failure-starting-process-in-perview-with-windows-10-universal-application?forum=wpdevelop).
PerfView, even elevated, should run the application as the normal non-elevated user.
It is obviously feasible as said here: https://blogs.msdn.microsoft.com/winsdk/2013/06/17/launching-a-process-as-a-normal-user-from-an-elevated-user/ It is even easier in PerfView as when PerfView starts non-elevated, it knows who is the normal user and it can collect the non-elevated token and pass it to the elevated PerfView process.
Thank you.
Tested with PerfView 1.9.0.0
TEST:
- Run PerView.
- Alt-R
- Type-in command to the application.
- Click on run command.
- Check in the task manager that the application as been launched with elevated privileges (admin user).
IMPACT:
- Windows Store applications can not been profiled this way.
- That is a security threat since the application has admin rights, and usuallly it was not designed for that.
- The developper can not profile its application as a normal non-elevated user (the behavior of the application can be very different).
I am assuming everyone understands the obvious work-around of simply using the 'Collect' rather than the 'Run' command. If you start PerfView's collection you can then launch your app however you wish, (and in particular non-elevated). This should not block investigations, and thus is a convenience/security feature.
This feature is a bit more complex because you probably want to expose the ability to run the app elevated as well as non-elevated (non-elevated can be the default).
I am generally supportive of this feature. If anyone in the community wishes to tackle it I can provide advice about the details necessary to get it done.
Hey @vancem, What about if we add a checkbox next to the Command text box (RunCommandDialog.xml) and if is checked then the process is started elevated.
@ppozeti - Sure having a checkbox to choose is reasonable. The solution is straightfoward, the issue is the priority. Because it has such a simple work-around it has low priority. If anyone wants to take a crack at it by all means do so.
Well, can I do this? I'm just starting at contributing to open source projects and I thought that would be a good start. Could you assign this to me?
GitHub won't let me actually set the assigned to field to you, but this note indicate that others should not work on it without interacting here.
@ppozeti is this something that you're still interested in working on?
Sure!
Excellent. Then I'll keep this issue around. Do post if you have any questions or run into issues. Thanks.
@ppozeti Paulo, I'm assuming that you will address this issue for Windows only, right?
Hi @brianrob ,
Above, Vance seems to be indicating that Collect did not require escalation in the past (and that it would block investigations if it were to), but now it seems to be required. Is that the case? When and why did that begin? Is there a way to navigate around this requirement? Thanks for the help.
@windhandel, collection of kernel events including CPU samples has always required administrative privileges, and last I spoke with the ETW folks, there is no plan to change this. I think Vance's point above is that it's reasonable to not want to run the application being profiled as an admin if you are using the PerfView.exe run command.
I think you can use runas /trustlevel:0x20000 yourapp.exe on the run command line in PerfView.
I'm not sure if it's exactly the same as "non-elevated", but from experience, it was good enough for my use case when I was working on Visual Studio startup performance many (15?) years ago.
