Is RunAsInvoker a secret, even higher UAC setting?


Actually, RunAsInvoker is a secret, even lower UAC setting.

What RunAsInvoker does is to ignore any elevation request in the application's manifest and treat the manifest as if it had said

<requestedExecutionLevel level="asInvoker" uiAccess="false" />

which is the default behavior. The program simply runs with the same privileges as the code that launched it. There is no attempt to elevate.

This means that if you run the program from an elevated command prompt, then the program stays elevated. If you run the program from a non-elevated command prompt, then the program stays non-elevated.

Try it. Make sure RegEdit is not already running, then open a non-elevated command prompt and set __COMPAT_LAYER=RunAsInvoker, and then run regedit from that command prompt. The resulting copy of RegEdit is running without administrator privileges. You can see this by trying to edit something in HKLM.

While it's true that RunAsInvoker suppresses UAC prompts, that's true because RunAsInvoker doesn't perform any elevation. If you aren't performing any elevation, then naturally you don't need an elevation prompt. If the resulting process is elevated, then it means that the calling process was already elevated. You were already on the other side of the airtight hatchway.

Comments (20)
  1. xcomcmdr says:

    Why would *anyone* read “RunAsInvoker” as “Run as SuperAdmin” ?!

    1. EMB says:

      DOTA 2 wizardry ?

  2. alegr1 says:

    That’s handy to invoke regedit while being non-administrative user, to edit HKCU.

    1. If you are a non-administrative user, then regedit already runs as invoker without prompting for elevation, because it uses highestAvailable.

      1. alegr1 says:

        Just checked it in Windows 7. It invoked an UAC prompt with two login options: current User and Administrator.

      2. alegr1 says:

        And in Windows 8+, regedit prompts for elevation, too.

      3. Neil says:

        I think he means that he doesn’t want to bother with elevation if he’s only editing HKCU keys, although perhaps what you’re trying to say is that he should avoid using an account in the Administrators group for day-to-day use. Sadly there is still software that assumes single-Administrator usage. (And it was a printer driver too! Worked fine over the network, at least.)

        1. Ah, so there appears to be confusion over the phrase “non-administrative user”. By “non-administrative user” I mean “a user who is not an administrator (and is therefore never elevated)”; alegr1 appears to be using it to mean “a user who is an administrator but who is not currently elevated.”

          1. alegr1 says:

            Non-administrative user == member of Users (but not of Administrators)

    2. GovindParmar says:

      As an administrator you can still edit other users’ HKCU keys within HKEY_USERS

  3. Joshua says:

    I’m really hoping this environment variable gets standardized. I had to use it at build time to remove a requirement for “builds must run as administrator” as a tool used on-site requires admin but the same tool when used to prep the last steps of the build environment doesn’t. (The real privilege demand is write to installation directory–which obviously requires admin for any real install as there are services.)

    1. Nope, the environment variable is part of the app compat infrastructure and is not part of the programmatic surface. If you want to do this to your own tools, you can use the app compat toolkit to specify that this shim should be applied to your build tool.

      1. Joshua says:

        It would appear the Application Compatibility Toolkit cannot be operated from a service account.

      2. Erkin Alp Güney says:

        That is working around the workaround.

      3. Erkin Alp Güney says:

        That is working around the workaround.

  4. Vincent Povirk says:

    Heh, I wasn’t expecting a direct response to my tweet. What I actually want, and incorrectly thought this could provide, is the ability to use a non-admin user without getting UAC prompts, and effectively lose the ability to elevate any process at all. I am already using a dedicated admin account, and I don’t wish to disable UAC on my admin account, just for the others. But, for whatever reason, UAC is only a global setting and that’s not possible.

    When I tested this later, I found that I was not able to configure this variable on a per-user basis, it’s seemingly ignored when I log in. I understand that if I could, it wouldn’t make an actual difference in terms of security, since any program can set or unset it. What does make a difference is that I don’t provide an admin password when asked to elevate from a non-admin account. (The theory is that it prevents a malicious program in my non-admin account from tricking me into elevating something bad.)

    If you were able to add this variable to an admin account with one of the “Notify only when…” settings, where explorer is automatically elevated, then I guess anything started by explorer would also be automatically elevated, and it’d be about the same as turning off UAC on your admin account. (I assume the “Notify only” settings don’t give you an elevated explorer process in non-admin accounts, as that’d be even worse than turning UAC off.)

    I tested running regedit from a non-admin account in Windows 10, and it does run without a UAC prompt. I remember this failing in previous versions. I’m glad it was finally fixed.

    1. Chris says:

      It’s not in the Control Panel for UAC, but there’s an extremely easy Group Policy setting/Registry Key you can set to do this. Policy name “User Account Control: Behavior of the elevation prompt for standard users”. You can set it to “automatically deny elevation requests”. This will prevent UAC prompts from appearing for standard users, but it still will for admin users.

      https://technet.microsoft.com/en-us/library/dd835564(v=ws.10).aspx#BKMK_StandardUserPromptBehavior

    2. Joshua says:

      I thought you and Raymond had opposite definitions of higher.

  5. Marc K 4096 says:

    I’ve run into a couple of applications that seemed to have a manifest with elevation set for no good reason. This will be a good trick to try the next time I encounter that.

    1. ender says:

      Same here. I edited the manifest in one of them (it wasn’t signed either). Won’t have to do that any more.

Comments are closed.

Skip to main content