UAC and launching an exe on Finish

SJSJ
5th August 2011 07:48 UTC

UAC and launching an exe on Finish
Hello,

I have an installer which uses UAC plugin which has

1. RequestExecutionLevel set to user.
2. privileges raised in onInit using UAC plugin.
3. to launch an exe in the INSTALLDIR in the Finish page. This exe installs the application as a Windows Service, which is shortly started in the next step
4. UMUI for pages.

On Windows7, when the exe is launched by the NSIS installer using nsExec::ExecToLog, the service is installed and started without any error. Eventually, the service should start a web service, which it is not. I suspect, starting the webservice requires Administrator privileges to store config data in system folders.

Currently, when I run the exe through command line by choosing "Run as administrator", the application works fine, the web service starts and there are no permission issues. But when I run the application by starting it as a service (manually from Windows Services or through script), it does not seem to start the web service.

Is this an UAC issue?
Since installer is elevated, will it not run the exe also in elevated mode?
How do I launch the exe and give it suficient privilege?

Yathosho
5th August 2011 09:07 UTC

probably not an answer to your question, but i've noticed there can be different behaviour when using Exec or nsExec. i have previously found myself in the situation that an installer with admin rights would execute an application (which also required admin rights) with one command (Exec) but not the other (nsExec).

SJSJ
5th August 2011 09:34 UTC

Thank you for the quick response!
Yes, I have tried it using Exec too. It is the same behaviour, at least in this case.
As I mentioned, even when I start the service from Windows Services directly, the application does not start the web service.
So I doubt if it is do with how we launch it from script!
What I would like to know is if this is a case of UAC blocking the app? If so, will the UAC plugin help me in anyway to launch the application with right privileges.

LoRd_MuldeR
5th August 2011 13:14 UTC

If a child process is created from an elevated process, that child process will be elevated too.

That actually is a problem, if the installer needs elevation, but you want to launch the application in non-elevated mode.

With "RequestExecutionLevel Admin" you make the installer (and all its child processes!) execute in elevated mode.

All the purpose of the UAC plugin is: Have the installer run elevated, but still be able to launch child-processes non-elevated.

UAC plugin does this by running two instances of the installer. The "outer" non-elevated one and the "inner" elevated one.

The "inner" instance is the actual installer instance, but it can ask the "outer" instance to do things in a non-elevated way.

In your case you probably do NOT want this behavior, as you want the child process to be elevated (just like your installer).

So I don't see why you need to use the UAC plugin, rather than a simple "RequestExecutionLevel Admin" :confused:

BTW: If your installer is not running elevated (i.e. "RequestExecutionLevel User" + no UAC plug-in) and you try to launch an application that explicitly requires elevation (by embedded Manifest), then Exec() will simply fail. You need to use ShellExec with "runas" verb instead...

Yathosho
5th August 2011 18:43 UTC

also have a look at this recent topic

Anders
5th August 2011 20:45 UTC

Originally posted by LoRd_MuldeR
You need to use ShellExec with "runas" verb instead...

If the exe has a manifest you don't really need the runas verb, the shell will detect it for you. (on NT5 you need the verb, but there you can "elevate" with a non admin user also so...)

MSG
5th August 2011 22:02 UTC

Don't Vista and higher ignore the levelrequest in the manifest when UAC is turned off?

LoRd_MuldeR
5th August 2011 22:17 UTC

Originally posted by MSG
Don't Vista and higher ignore the levelrequest in the manifest when UAC is turned off?

Well, if UAC is turned off (generally a bad idea!), then "elevation" is not needed/possible.

UAC works with two access tokens:
One "full" token which contains the full rights of the user account and a second "limited" token with minimum rights.

By default an application get's the "limited" token. Via elevation it can get the "full" token instead.

Without UAC, however, there only is a single "default" token...

MSG
5th August 2011 22:29 UTC

Originally posted by LoRd_MuldeR
Well, if UAC is turned off (generally a bad idea!), then "elevation" is not needed/possible.

UAC works with two access tokens:
One "full" token which contains the full rights of the user account and a second "limited" token with minimum rights.

By default an application get's the "limited" token. Via elevation it can get the "full" token instead.

Without UAC, however, there only is a single "default" token...

Hmm, UAC probably did introduce the term elevation... But I was referring to running at higher privileges, regardless of whether UAC was involved or not. If elevation is something else, what's a good shorthand for 'running as admin'? >_>

Anders
5th August 2011 23:33 UTC

When UAC is off, the runas verb is broken on NT6 (It works on NT5 but you can use a non admin user in the combo box)

LoRd_MuldeR
6th August 2011 00:41 UTC

Originally posted by MSG
Hmm, UAC probably did introduce the term elevation... But I was referring to running at higher privileges, regardless of whether UAC was involved or not. If elevation is something else, what's a good shorthand for 'running as admin'? >_>

Well, I think, on pre-Vista systems running "as admin" means running as a different user, if the logged on user doesn't have admin rights. On these systems the process always gets the full rights of the user. The only way to prevent processes from getting full rights on these systems was logging in with some "limited" user account. And only if you did that, you'd have to run certain processes "as admin".

With UAC you no longer need to use "limited" user accounts. Running "elevated" means giving the process the full rights of the user. And it's required even for "admin" users. That's because, with UAC enabled, processes get only limited rights by default - even if run by a user with full admin rights. So you can use safely use an "admin" account for regular work. At least that's the theory...

Originally posted by Anders
When UAC is off, the runas verb is broken on NT6 (It works on NT5 but you can use a non admin user in the combo box)

In my experience it will trigger an UAC dialog :confused:

Anders
6th August 2011 01:29 UTC

Originally posted by LoRd_MuldeR
On these systems the process always gets the full rights of the user.

Not 100% true, you can give a admin token to CreateRestrictedToken or the Safer API and create a process that does not have admin rights (The (run as dialog) protect my computer checkbox on XP/2003), but from a security point of view this was not enough because of shatter attacks and other issues. The NT6 limited token is probably similar to this but with the added security of UIPI (and IL) and session 0 isolation...

SJSJ
8th August 2011 05:33 UTC

Thank you, all, for your responses.
I used UAC plugin and "RequestExecutionLevel user" because the installer process needed to install it for a user, create shortcuts for local user etc.
Only the exe called in the finish page needed an admin privilege.

One more strange observation which I failed to mention in my post was that this problem occured only during a first-time install. After installation, the first time the application is run as service, the service starts, it calls the exe, but the exe fails to launch the web service.

Once the service is restarted, everything starts working again - including the web service. Similarly, if I uninstall the first installation and install once again, there is no problem seen in running the web service.

Now, I am beginning to think there is Access control involved too.

LoRd_MuldeR
8th August 2011 12:22 UTC

Originally posted by SJSJ
Thank you, all, for your responses.
I used UAC plugin and "RequestExecutionLevel user" because the installer process needed to install it for a user, create shortcuts for local user etc.

How does this prevent you from using "RequestExecutionLevel admin" ???

UAC elevation generally will not run the installer with a different user account, but run the process with the full rights of the current user account - instead of giving the process only small subset of the current user's rights. Elevation is required even for "unrestricted" (admin) user accounts. Still the (elevated) installer process will run in the context of the current user account.

See here:
http://forums.winamp.com/showpost.ph...87&postcount=8

AFAIK UAC elevation would only trigger a "Login" (aka run as a different user) dialog, instead of the normal "Elevation" dialog, if the installer is run by a user with an "restricted" (non-admin) user account. But then the problem is not UAC, but the fact the current user simply doesn't have the required rights to install (and therefore shouldn't be running the installer anyway).

Also it might make much sense to create shortcuts for ALL users, rather than for a single user who happened to run the installer.

MSG
8th August 2011 13:49 UTC

Now you're just making things complicated. He/she needs admin access to register a service. Elevating will get that access. It doesn't matter whether the access is given by UAC to a UAC-protected adminlevel user, or by secondary logon to an admin user parallel to the current user.

So using the UAC plugin to elevate the installer works just fine for what he wants to do: Installing an app at userlevel, and installing a service as admin.

(Whether or not that's a good thing to do is an entirely different matter. I don't know much about services but afaik they run for all users. In that case the app should probably also be installed for all users...)

LoRd_MuldeR
8th August 2011 14:16 UTC

Originally posted by MSG
Now you're just making things complicated. He/she needs admin access to register a service. Elevating will get that access. It doesn't matter whether the access is given by UAC to a UAC-protected adminlevel user, or by secondary logon to an admin user parallel to the current user.

Hmm, I think it does make a difference for $SMPROGRAMS (in "user" shell context), which was one of his concerns...

MSG
8th August 2011 16:24 UTC

No, anything user-level should be done in the outer instance (userlevel instance) of the installer. It doesn't matter whether the inner instance (admin instance) is the same user or a different one.

(Of course you shouldn't do anything in user shellcontext in the admin instance. But that's pretty much a given. You use the admin instance to make system-wide changes, not to create shortcuts in an admin profile...)

SJSJ
12th August 2011 09:55 UTC

Thanks for your replies.
The problem seems to have occured in another portion of the code. The web service was trying to create temp config files inside system32\config\systemprofile\appdata when it didn't have sufficient privileges.
Fixed it by providing an accessible temp dir and things worked.

A special note of thanks to all of you who responded to my query. NSIS forum rocks!!