0

I have an application that runs using as AsInvoker manifest, this uses ProcessStartInfo to run another application that is using a HighestAvailable manifest (in my case this runs as Admin and I get the UAC prompt) the first app then quits.

The second app then uses ProcessStartInfo to run the first app again, this time it runs as admin (no UAC prompt) I guess this is correct because it is AsInvoker and it is being invoke from an application that is running as admin, but I actually want it to run without Admin rights - or more correctly run it with the lowest possible execution level

I know you can use ProcessStartInfo.Verb = "runas" to elevate but can you descend?

Matt Wilko
  • 26,994
  • 10
  • 93
  • 143

2 Answers2

0

No, you cannot "go back down" (There are several answers on this site and external tutorials that claim otherwise, but they all have problems in certain scenarios, this answer from a MS employee confirms that this is the case)

Your only real option is to use a AsInvoker bootstrapper/parent process that can launch unelevated processes. (And even this will fail if the bootstrapper is started elevated, but in those cases the user manually chose to run as admin)

Community
  • 1
  • 1
Anders
  • 97,548
  • 12
  • 110
  • 164
  • Can't help thinking that we need a new level entitled `LowestAvailable` – Matt Wilko May 11 '11 at 12:43
  • @Matt: That would mean that every process would need to keep a open handle to the lowest integrity token it knows, and pass it on to its child processes. But even that would fail since UAC can elevate with a different user and then there would not be a < High IL token at all. – Anders May 11 '11 at 13:54
0

@Anders is saying you can't level your own process back down, and that's right. But the OP is asking about launching a non-elevated process from an elevated one.

According to Aaron Margosis (also a Microsoft employee, not that I'm dissing Larry who is a hero of mine) that can be done. An MVP has written a managed wrapper for Aaron's native code.

Use with care.

Kate Gregory
  • 18,808
  • 8
  • 56
  • 85
  • No, I'm not talking about just your own process, I'm talking about starting child processes as well. Take Aaron's code; it fails if the shell is not running. Also, if the parent process user is not the same as the shell, you end up running as the wrong user (One of the grandparent processes was started with runas.exe/CreateProcessAsUser etc) – Anders May 12 '11 at 16:02
  • 1
    OK, so we agree. Best bet is an non-elevated process that continues to run the whole time, and launches elevated/non-elevated child processes as required. If for some reason that is rejected solution, there are other solutions but they are don't work in every scenario. They do, however, work in the ones installers are likely to run in. – Kate Gregory May 12 '11 at 16:13