Vista/7 UAC: how to lower process privileges

Question

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

Answer 1

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/

Answer 2

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.

Answer 3

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."