AutoUpdater.NET
AutoUpdater.NET copied to clipboard
ravibpatel
AutoUpdater starts app as a different user after updating
I have an application using named pipes for IPC and after updating the access to any named pipe is denied. What user does the application run as after the update?
I need admin because the program is in Program Files. RunUpdateAsAdmin is set to True of course. But after the update is applied by ZipExtractor the App should not start as Admin?
My problem is that after the update any named pipes I create in the program are denied access by normal apps ran by the same user. I have to manually quit out of the app and start it again.
Named Pipe security options management is broken in .NET Core 3.1 and it won't be fixed until .NET 5, so I can not work around the issue either.
@prj If ZipExtractor is running as Admin, then it will start the app as Admin. Can't you just upgrade the app to .NET 5.0?
No, because if I just silently update all users to 5.0 then nobody of them will have the runtime. Furthermore I am on 3.1, which is the LTS.
Either way, this is not the solution to the problem. You are asking me to fix the symptom by upgading my app to .NET 5 and then changing my code to change the pipe security to allow other users.
Why can the actual user not be impersonated when the app is not restarted? There are API's to do that in Windows and the Admin can impersonate any user. To me this seems more like a bug/oversight, a pretty bad one at that.
I worked around this by doing a very ugly hack of taking the .net core 3.1 source from repo and creating a custom System.IO.Pipes package in another namespace, all that to add a single constructor. This still does not change the fact that ZipExtractor should impersonate user when starting app.
From a quick search it should be possible to pass a user to Process.Start. Win32 api also has CreateProcessWithLogon call.
Issue with this is it requires a username and password to launch the process as that user. If user have password, it won't be possible to provide it.
I didn't try it, but I tried providing username to Process.Start, if you have a password, then it fails.
I looked into it a little and I stand corrected. It does need credentials. With some interop trickery it might be possible via NtCreateToken without credentials if you are admin, which in this case is true.
It is possible to use explorer.exe to launch it as current user, but there is a side effect. Currently, It launches the application with all arguments that are passed to the application. If we launch it using explorer, then it won't pass them.
That also isn't good. The argument list is very important, since applications can have totally different behavior then. Is it possible to create a temporary .bat file and then launch that with Explorer?