Archive: Vista + Run App On Install
Vista + Run App On Install
On Vista, when the installer finishes and shows the 'Run Your Application' checkbox, the installed application is run as an administrator. This happens because Vista elevates the installer to require admin, and the launched process inherits the security status of the app which launched it.
Is there any fix or planned fix for this problem?
I am using version 2.22 of NSIS.
Thanks.
A quick Google search found the following MSDN article.
http://msdn.microsoft.com/library/de...re11152004.asp
Maybe it can be made into a plug-in. I won't include that as the default, because the installer might need to execute other programs that need administrator rights, but maybe it can be an option.
In trying to find a solution for this problem (our patcher does the same thing as the NSIS installer), I came across DropMyRights. Using the safer libraries does not seem to work properly on Vista since it uses the current processes security token. Vista creates 2 separate security tokens (one admin, one standard user) on login, and if you are a standard user, running an installer prompts you for the admin account of a different user. So, the current process token is obviously not the one to use, and calling CreateProcessAsUser with a different token than the calling thread will usually fail with access denied.
It seems MS' solution is structure installers into two parts:
- A launcher that runs as a normal user, launches the admin part, waits for it to complete, & then launches the app
- An app or com object that the launcher calls to request admin access and performs the installation
The other solution is to use the system task scheduler to create a task and schedule it immediately to run as a normal user. This seems kinda hokey.
I would imagine that the majority of installers using the 'Run app' feature would be launching a standard user app, an would take care of any administrative needs in the install script prior to finishing.
Hmmm, "system task scheduler" is a service and not guaranteed to run on the Vista PC, would not follow that path really...
ya. as i said, seems hokey :)
I loaded up MS' sample code for the task scheduler, and it fails to work properly when you have a standard user elevate the process w/ a different admin account. The process is started on the admin's desktop, not the current users.
What happens if you shellexecute a shortcut?
Have not time to make a NSIS tryout for this situation myself (yet), but it might be worth a try.
The question is: How do i make a Launcher setup that runs in a user mode? From what i understand, we need to use an embeded manifest in the launcher. one like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<!-- The tag options -->
<!-- <requestedExecutionLevel
level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/> -->
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
How can we do it? Or is there another option to run the launcher in user mode?
Running a "normal" process from an elevated UAC process doesn't seem to be very straight-forward. Google for "WindowsVistaUACDevReqs.doc" and see the note on page 73, plus the sample code towards the end of the document.
I guess it wouldn't take much to wrap that code up in a plug-in DLL, though it's a shame MS didn't think to include it without jumping through so many hoops!
Si
I got interested in this question because of an article on Vista
and UAC in the January 2007 issue of MSDN Magazine which sees this as a "typical problem" with installation programs:
"It is very common to start an application at the end of installation.
Unfortunately, the application is often started under the wrong user
contextbecause the user provided elevated credentials to perform the
installation and the application is created with the elevated user
token." (from page 49)
Their suggestion, which does not seem ideal, is the one mentioned above by
Locke355: a separate launcher .EXE that first runs the installer (which
is marked to request elevated privileges) and then runs the application.
To instead try to do it from a single NSIS .EXE installer, the following
links look relevant to me, though I haven't actually tried any code yet:
"Understanding and Working in Protected Mode Internet Explorer" at http://msdn2.microsoft.com/en-us/lib...aspx#dse_stlip
and
"Windows Vista for Developers – Part 4 – User Account Control" at
http://weblogs.asp.net/kennykerr/arc...t-Control.aspx
and
"How to CreateProcess NOT as administrator" http://forums.microsoft.com/MSDN/Sho...22705&SiteID=1
The first two have relatively simple sample code showing how a medium
integrity Vista process (that is, a process with normal privilege
levels) can create a low integrity process (the level that protected
mode IE7 runs at). This is very close to the question at hand, which is
how to have a high integrity (elevated administrator) process create a
medium integrity process.
The third link above is a thread (with links to other threads) with some
not-too-optimistic comments on various suggested methods of handling this.
From what I understand, going from medium -> low integrity is easy because your security token essentially remains the same. However, going from administrator -> medium changes the security token. Further, when you are using OTS (over the shoulder) promotion to some other administrative account, the current user token is not even your own.
AFAIK, any solution which requires CreateProcessAsUser will fail because, by default, administrator accounts on Vista do not have permission to run a process as another user.
I have found 3 solutions to the problem. If anyone has found anything different, please reply. They are:
- Create a launcher app as listed above, or have the installer relaunch itself requiring administrative access on vista. The installer needs to tell the medium integ. process to run the app when finished.
- Create a COM control to do the install. However, the COM control needs to already be registered before elevating, so this can become a catch-22 situation.
- Create a service which launches the application. I am unsure if admins can lose their rights to start and stop a service, but this solution has the same catch-22 problem as the COM solution. Also, who wants to require a service starting and stopping just to run an app?
In my app, it was acceptable to remove the 'Run app on install' feature, at least until the problem is solved in NSIS or I implement solution #1.
Originally posted by oboI believe the code at the bottom of the page is the task scheduler code? If so, see my comment above on the app starting on the wrong desktop.
Running a "normal" process from an elevated UAC process doesn't seem to be very straight-forward. Google for "WindowsVistaUACDevReqs.doc" and see the note on page 73, plus the sample code towards the end of the document.
I guess it wouldn't take much to wrap that code up in a plug-in DLL, though it's a shame MS didn't think to include it without jumping through so many hoops!
Si
IDEA:
Suppose you create a temporary shortcut to your application with a HOTKEY assigned then send the keymessage from within the installer then delete the shortcut again, would dat not start the application as if the user clicked on it with these rights?
(Just trying to be creative and come up with a solution, so plz no flamewar)
That is an interesting idea. I am not sure how you would detect if the shortcut hotkey already existed. I also do not know if a simulated key message will trigger a shortcut hotkey.
> From what I understand, going from medium -> low integrity is easy
> because your security token essentially remains the same. However, going
> from administrator -> medium changes the security token. Further, when
> you are using OTS (over the shoulder) promotion to some other
> administrative account, the current user token is not even your own
I don't think there is any issue with whose security token is used.
Historically, when the Setup program running with administrative
privileges shells out to your application, your application runs under
the same userid and with the same privileges as the Setup program did.
With the code discussed below, a copy of the Setup program's security
token, with the only change being its integrity level, is used for the
child process.
The attached code, adapted from http://weblogs.asp.net/kennykerr/arc...-Control.aspx,
seems to work for me.
It should be launched from a cmd.exe session with High integrity.
It then launches Notepad with Medium integrity.
The attached screen shot shows the Administrative cmd.exe window, a
message box from the test program, and Notepad. It also shows output
from the current version of Sysinternals' Process Explorer, showing the
cmd.exe window with High integrity and Notepad with Medium integrity.
I have not run your test code, but, I am curious: if you run the installer with OTS elevation (standard user has admin type in his password to run the app), and use your approach, the program which is run at the end of the install (in this case, notepad.exe) will run as the admin account, no? As a user, I would expect the installed application to run as the standard user, not the administrator.
Also, when an admin initiates the installer, are the privilege flags identical in the launched app to any other app run w/ medium integrity from explorer? You can check this by right clicking on the process in proc explorer, and going to the security tab.
This thread is fairly dated now, but I came across it while looking for a solution to installers for Vista, so I thought I'd point out the following plugin:
http://nsis.sourceforge.net/UAC_plug-in
It allows your installer to run with elevated permissions, and still drop back to the regular user login for launching apps post-install.
The strategy from kjk7 up above about running with a decreased integrity levels won't work in the general case because the user may be using Run As... to launch the installer (or may elevate into a different user entirely if the current user doesn't have admin rights to begin with).
Definitely recommend the UAC plugin - it works like a champ.