JonHodgson
20th September 2011 10:26 UTC

RequestExecutionLevel admin doesn't seem to do anything
Hi,

I have an installer that really needs to run with admin priviledges.

I can run it fine from an admin account... no surprise there.

But when I run it from a user account, the best I seem to be able to manage is to get it to detect it does not have admin priviledges and exit.

RequestExecutionLevel admin seems to make no difference.

Neither it seems does right clicking and selecting "run as administrator"

So how do I get it to run with admin priviledges from a user account?

LoRd_MuldeR
20th September 2011 12:18 UTC

"RequestExecutionLevel" does nothing but adding a Manifest to the EXE file.

This will trigger elevation on Vista+ systems that have UAC enabled.

However it does absolutely nothing on pre-Vista systems as well as on Vista+ systems with UAC turned off.

That's why you still need to check for Admin rights at runtime, as suggested all the time on the forum...


I would recommend to give the UAC plug-in a try:
http://nsis.sourceforge.net/UAC_plug-in

That is the code I currently use:
http://pastie.org/private/8eaggwflkvn3shecyvjng

JonHodgson
20th September 2011 13:34 UTC

I've implemented the check at runtime, that works.

But what I can't seem to do, despite having requires admin rights in the manifest, AND selecting "run as admin" from the explorer context menu, is to actually get it to run with admin rights from a non admin user account.

I'm working on Windows 7 64 bit (though it's a 32 bit installer and app)

I shall try your code

LoRd_MuldeR
20th September 2011 14:01 UTC

With "RequestExecutionLevel admin" and running on Vista+ and UAC enabled, the following should happen:

(1) User with admin-privileges runs the installer:
An UAC dialog pops up and asks the user to confirm (click on YES button is sufficient, NO button aborts)

(2) User without admin-privileges runs the installer:
An UAC dialog pops up and asks the user to enter login credentials of an Admin account.

In both cases the installer should either start with elevated ("admin") rights or not start at all. Also you don't need to use "run as admin". This is for legacy applications that need elevation ("admin" rights) but are lacking a proper UAC Manifest to enforce.

Again, on Windows XP (or even older) the UAC Manifest does nothing. So on these systems the installer would start with the privileges of whoever has launched the installer and you need to check yourself, at runtime, whether we are Admin or not.

BTW: The great UAC plug-in allows you to do "elevation" even on Windows XP (it will pop up a "run as" dialog, if the installer was run by a Non-Admin user) and it allows you to handle the situation when the user has clicked "NO" in the UAC dialog on Vista+ systems (so you can show a message like "This installer needs elevation. Please try again!" and then re-run the installer to give the user another chance).

IMPORTANT: If you ever try the UAC plug-in, make sure you use "RequestExecutionLevel user" and let the plug-in handle all elevation!

MSG
20th September 2011 14:43 UTC

Please do not recommend the UAC plugin for something as simple as elevation. Elevation is NOT what the UAC plugin should be used for. The only thing the UAC plugin was designed to do is allowing the finish page's Run checkbox to launch the app at userlevel, after elevation has occured for the installer.

To enforce admin-only installations, use the userinfo plugin in .onInit, with a messagebox + quit if access level is too low.

JonHodgson
20th September 2011 14:47 UTC

What you describe is what I expected to happen.

But not what I'm getting.

Windows 7 seems to be completely ignoring the requirement for admin rights when running the installer... though not when bringing up errors when it tries to do something that requires admin rights.

I've checked and it is in the manifest.

the UAC plugin example installer seems to work as it should, so that seems like a working solution to what I need to do, but I'm still confused as to why I'm not seeing the behaviour you describe.

LoRd_MuldeR
20th September 2011 14:53 UTC

I disagree ;)

Being able to launch application in a non-elevated way from an elevated installer already is an essential feature for me. But being able to force "elevation" (i.e. automatically trigger a "run as" dialog if installer was run by a non-admin user) on pre-Vista systems is very useful too! Last but not least with UAC plug-in I can handle the situation when elevation has failed (e.g. the user has accidentally clicked on "NO"). Without UAC plug-in my installer would never be started in that case, so I cannot handle anything. Bad for Auto Update and stuff...

(This doesn't mean everybody needs the UAC plug-in, but everybody should be aware what it can do)

@JonHodgson
What UAC level is configured on your test system? Also, what actions exactly do cause errors?

MSG
20th September 2011 15:12 UTC

I don't think everybody should be aware of what it can do. It's a relatively complex tool for only a small added feature (being a shiny run as dialog). You shouldn't push any and all beginners towards something that will in the best case cost them a huge amount of work to figure out, and in the worst case cause them to give up completely.

JonHodgson
20th September 2011 15:47 UTC

Where is the UAC level set?

LoRd_MuldeR
20th September 2011 16:05 UTC

In the control panel:
http://img191.imageshack.us/img191/482/uaccontrol.jpg

JonHodgson
20th September 2011 16:26 UTC

Thanks,

Ok, here's what I've found.

At some point I turned UAC off, probably because with all the installs and updates I was doing setting up a new system it was just a pain.

Anyway....

If UAC is any level of on, then things are as described by others here, I try to run the installer from a non admin user account and I get a dialog where I can put in an admin password, and it then runs properly.

But...

If UAC is switched off, I don't get any such dialog (not too surprising), but the installer doesn't work, because for example that user doesn't have write permission to Program Files (x86)

Maybe that makes sense to Microsoft, or someone here, but it doesn't to me. I would have thought that switching UAC off would switch off the protection against users modifying the system, but all it seems to be doing is switching off the means to elevate over that protection.

Now I think that a simple check of admin rights will result in an installer that will work first time for most users, so that's fine in itself, but I'd still like to understand the thinking behind how things are working.

LoRd_MuldeR
20th September 2011 16:33 UTC

As said before, without UAC (pre-Vista OS or Vista+ with UAC turned off) the UAC Manifest doesn't do anything.

So if the installer is launched by a Non-Admin user with UAC turned off, it will probably run with that user's limited rights.

Do what MSG has suggested: Use the UserInfo plug-in in .onInit and abort if the rights are not sufficient...


Keep in mind:

On Windows every user has a security "Token" containing its rights and generally applications are launched with the user's token. At least that was the situation before UAC (and still is the situation with UAC turned off). If a "regular" user, who has limited rights, launches an application, the application will have limited rights too. If an Admin, with maximum rights, launches the application, the application has maximum rights. Now, with UAC in action, each user has two tokens: A "restricted" one and an "unrestricted" one. By default applications are always launched with the "restricted" token - even if you are an Admin user! Elevation, which can be enforced by Manifest, will cause the application to be launched with the "unrestricted" token, but only after the user has confirmed. AFAIK "Admin" users just have to click "YES", but a "Non-Admin" user will be prompted to enter the login credentials of an "Admin" user in that situation (so it can borrow the Admin's "unrestricted" token for the installer process). With UAC turned off elevation doesn't happen! And so the application is simply launched with the user's token, which has limited rights - not because of UAC, but because the user is a "regular" (Non-Admin) user...

Anders
20th September 2011 17:37 UTC

http://pastebin.com/EvMkyLLt is as simple as you can get it