Is it possible for a process to lower itself from elevated UAC permission back to standard user? If not can the elevated process launch its copy with standard user token and then kill itself? Any code examples (C# preferred)?
Details:
Problem:
- user installs my product (written in C#)
- the installer elevates its UAC permission to admin
- at the end the installer launches my exe
- the exe inherits elevated permissions from admin
- the exe mounts network drives which become invisible in Windows Explorer (that runs with regular permissions)
Options I considered:
1) break installer into outer exe and inner exe, that runs with elevated permission. The install consists of 1000+ lines of NSIS code and I don't know anything about NSIS
2) mounting drives with lower permissions. If I do it Win Explorer can see the drives but my exe cannot
3) setting EnableLinkedConnection registry option to 1. This is a no-go because it requires PC reboot during the installation.
Please help!
Sergey
One way: http://www.codeproject.com/KB/vista-security/VistaElevator.aspx
Another way (mentioned in most recent comment in previous article): http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/
It is impossible to get this working in all configurations, there are ugly hacks like Kyle links to, but in the end, there is no real way to lower your rights. Since you mention NSIS, it so happens that it does have a plugin called UAC that does the inner/outer instance dance, it's not pretty but it does work.
If you're fine with a "hack" answer, another blog post about NSIS shows a much simpler approach. Just using explorer.exe to launch another process seems to work.*
The C# would just be
Process.Start("explorer.exe", YourProgram.ExecutablePath)
Beware that even if you WaitForExit() explorer, your program likely hasn't finished yet!
*Also beware one of the comments: "Unfortunately, the Windows Shell team has replied that the current behavior of "Explorer.exe AppName.exe" is a bug and may not work in future updates/versions of Windows. Applications should not rely upon it."
Related
I am currently coding a WPF project. The project is a sort of Task Manager program. Inside of the project, there are methods that take real-time PC data (temp, frequency, etc). However, some of the methods in the project require administrator privileges, so that the program can have access to the different values/data from the PC.
The problem at hand is that the program asks for these permissions every time the program is run. While I know this is just a personal preference, I would like to make the program only ask for the said privileges at installation/first run, so that the user does not have to authorize their permission every time.
Just to be clear, this is not a question about how to get the administrator privileges in general. I know that there is the option to manipulate the app.manifest file. This question is only pertaining to keeping the set administrator privileges programmatically, or through other means such as visual studios.
(Also, the program uses NSIS as an installer, if this is at all helpful)
Thanks
EDIT:
Looking back at this question, it was a pretty stupid one. It was just due to my sloppy/lazy coding.
That is not possible because the purpose of UAC Prompt is to create awareness for the user so they know that they are allowing admin privileges to the software.
I Do not really advise you to skip the step of the prompts.
You can not do it directly but you can indirectly , if you can write a code to do the following steps here , you can achieve what you asked for.
Windows is a secure operating system. If the user is not an administrator: then you don't get to control that.
What would your application have done under Windows XP?
Would it have crashed?
Would you have refused to run?
Would you have told the user that they need to be an administator?
Is there no lesser mode you can use that can still give the user useful information? After all, Process Explorer is still able to run and give me all kinds of useful information about processes on the computer.
But if the user is a standard user, you have no way to change that at install time.
I have a WPF application which will be used on tablets with Windows 10.
In my development environment, the application runs very fast. However, if I run the application on tablet without admin rights, the application responds very slow : all animations are slow, the scrolling is not smooth, and touch problems are visible (cannot move the caret). If the application has admin rights all things are working fine.
I tried to disable the logs, I tried to decrease the FPS, nothing seems to help.
My application is connected to a sqlite database, but even without accessing the database is very slow. There are no other connections that may require admin rights.
What could be the problem?
EDIT: Also in my dev environment the app is running slower without admin rights. I was running the VS2015 with admin rights and for that reason the application worked fine.
WPF has settings under HKEY_CURRENT_USER that can disable hardware acceleration:
https://msdn.microsoft.com/en-us/library/aa970912(v=vs.110).aspx
If the Disable Hardware Acceleration Option or the Use Reference Rasterizer Option are set, a WPF application will run slowly for that user.
Try to trace your app with Process Monitor. Run 2 traces for app running with and without admin rights. Filter your app events only via Tools->Process Tree... -> right click on your process -> Add to Include filter and compare these trace logs (or just post them here). Pay attention on gaps between registry key readings or network access.
That literally could be anything.
Mark Russinovich make a presentation almost every year about finding some interesting cases. Here's one of them.
P.S. I'm sorry to post that as an answer, but I don't have enough points to add comments right now.
To offer an answer for people that might face the same issue, now, after I've searched a lot for something helpful, I can say that this problem it is mainly a problem related to rights.
If you encounter this issue, try to run Visual Studio without admin rights and try to isolate the region where the application begins to act very slow (or the place were it crashes) . In my case, wasn't the database, or the log files, but a file in AppData which was used by an external assembly. I've seen that, every time that dll was called, the application was freezing and using dotTrace, I've managed to find which file it is used. After setting the rights (r/w) on that file, everything was back to normal.
I have a small application which is a single executable. For context, this is deployed to Thin Client computers and runs automatically at boot. Users do not have the rights to close this application.
However, I need the application to be easy to update. I can't write my software to do any kind of auto-update routine, because these stations often have a write-blocker* which must be disabled beforehand.
The simplest solution as an administrator is to copy the new EXE over the old using the various tools provided with the Thin Client, or Group Policy / scripting where required. The update doesn't have to be instantly effective - the next reboot is fine.
The problem with this is that, of course, the executable is in use and can't be overwritten. What's the best way to allow this to happen? Load the software completely into memory and run from there? Do some kind of routine which copies the exe to a temporary folder and then executes it with a command line switch so it doesn't endlessly loop?
*This may have caused some confusion. These are Windows XP / Windows 7 Embedded machines. For the most part they work like normal computers, except file system writes are transparently redirected to a cache drive. On a reboot, all changes are completely reverted. A normal script to update the machine would go something like:
Disable Write Blocker
Reboot Machine
Copy Files
Reboot Machine
Enable Write Blocker
Reboot Machine
However, my application will autostart after every reboot as there's no mechanism to inform it. As such, when the scripts get run the executable is still in use.
You might be able to use Windows' MoveFileEx with the DelayUntilReboot option.
To do this from C#, see this answer which shows how to set up the call to the Windows API.
Note: I think the call needs administrator privileges.
You could make of use of something called Shadow copying assemblies. Search the net, you'll find lots of examples (also on SO and Codeproject).
Obviously the application can only update if your write protection is disabled. Are you using FBWF or EWF? You might even exclude the application folder from write protection.
Basically, I have an exe app that is installed with priviledges (as in, the user presses the "Allow" button in Vista/Win7 UAC check), then the application starts and sets itself to auto-run so that the application will automatically restart again once the computer is rebooted (all done while elevated). The autostarting is requested by user, and is not enforced upon them.
This reboot instruction is set in the registry, in the CURRENT_USER section as below:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
The problem is, when the computer reboots, Windows will not let it execute unless the user re-authorizes it as an elevated process again (namely, a taskbar icon pops up in the tasktray saying the starting of my EXE/process was prevented, and the user is given the ability to launch the blocked app using menus on the icon in the tasktray).
I would like to add that I have the manifest file integrated into the EXE, so there is no problem on that end, and it registers its intentions accurately in the XML file.
Why does Windows do this by design? If an exe was authorized once, shouldn't that imply that it be authorized permanently?
But the main question I would like to ask is, how do I get around this? Imagine my users having to do this every single time the application needs to autorun?
Also, I would like to avoid the whole "your app shouldn't be running in elevated mode in the first place" argument/discussion, or the "no app needs elevated priviledges, you need to rewrite it" discussion. I can assure you that my app needs elevated priviledges (unfortunately). More details below if interested, not necessary to interpret or understand the question in this post, but included because I know some people will ask)...
Additional Unnecessary Reading:
...In fact, it requires it in 87% of all launches (depending on what users do), and for the 13% of times were it is not needed (that's, 13% of all launch instances, not 13% of users), I am developing a second exe where only that is launched first, and once an elevated feature is needed/requested, the elevated portion loads, saving 13% of all launches from hassling people with UAC nag, I will only have this ready by 2013. I'm going to all this work to split up functions that don't logically belong in different areas of the application - even with all this work, the problem I mentioned above does not get resolved (but rather, very slightly minimized or deferred).
I'm not sure why this was tagged with any programming language, and since it is really a ServerFault question it doesn't even belong here as far as I can tell.
The normal way to handle this is via Task Scheduler though, using the Run with Highest Privileges option. There are several published descriptions of the process involved, such as the old one at Make Vista launch UAC restricted programs at startup with Task Scheduler.
Why does Windows do this by design? If an exe was authorized once,
shouldn't that imply that it be authorized permanently?
That's a matter of opinion, but here's mine. If I needed Visual Studio to run elevated yesterday because I wanted it to regsvr32 a DLL, that doesn't prove that I want it to run elevated today on some different app.
But the main question I would like to ask is, how do I get around this?
I would use a service. The programming is non-trivial but that's how I would autorun an elevated process.
Either ask the user to turn off UAC or, as you already mentioned, redesign your application so that it elevates at the point elevation is needed, or run a service under system account and let it do the stuff which requires elevation.
I would like to know how to programmatically lower my application's privileges. So, let's say someone with admin privileges runs my program, I would like my program to still run under a normal user's environment or with less privileges that I don't need. Also, could you explain what is restricted in the lower trust environment?
Edit: Curtisk suggested the permview.exe tool to view an application's permissions, which lead me in the right direction to the newer permcalc.exe tool - http://msdn.microsoft.com/en-us/library/ms165077(VS.80).aspx. Thanks again.
The RequestMinimum Flag may be close to what you need, although it is zone/PermissionSet based, more details in the linked MSDN How-to.
The idea is it will run the application with the least set of privileges to function, regardless of who calls it...
Follow up on question in comments below: check out the Permissions View Tool