ksngs78
27th February 2009 00:22 UTC

ExecWait embeeded installation with Adminstartor rights
Hello,

I spent many hours in trying to find solution for following situation. My program doesn't need any "power" rights and is able to work under "normal" user. I wrote installer and use "APPDATA" as directory for installation. But my program uses third party library. Installation program of the library demands admin rights. So I need a way to execute the installer of the library under Administrator in case if the library is not installed. I looked at RunAs plugin but it demands creating of a dialog for inputing User&password. It's not acceptable for security point. Is there any solution for this?

Anders
27th February 2009 00:35 UTC

what I would do is, in .onInit, check if this library is installed, if its not (and the installer is not running as admin (check with userinfo plugin)), display a messagebox telling the user this and:

a) restart your installer with ExecShell and the runas verb
or
b) tell the user to restart your installer as admin

See also:
http://nsis.sourceforge.net/Driver_i...ion_and_update
http://nsis.sourceforge.net/InstDrv_plug-in
and search the wiki and forum for more info

ksngs78
27th February 2009 00:47 UTC

Yep. I already implemented checking of admin right and etc.
1) ExecShell with "runas" has an ability to wait the process until it finishes? I'm not sure that it's possible because ShellExecute (Windows API) doesn't return process handle in this case (When "runas" is used). So WaitForSingleObject won't work.
2) If I start my installer as admin the program will be installed for admin user but I need to install it for current user. I mentioned that I use "APPDATA" of current user as destination.

Anders
27th February 2009 01:08 UTC

ShellExecuteEx can return the child process handle, nsis does not support it out of the box, but you can call it with the system plugin or UAC::ShellExecWait (uac plugin)

The other option would be to rewrite your installer to use the UAC plugin, this way you can run as admin and still execute nsis code/extract files as the "current" user.

ksngs78
27th February 2009 01:17 UTC

I'm sorry. I mentioned ShellExecuteEx in the previous response. It doesn't return process handle for "runas" processes. ShellExecute doesn't have ability to get Process handle at all.

I tried to move forward with UAC plugin ... but I was confused and didn't understand how execute code/extract files as behalf of current user. Also "APPDATA" points to path of Administrator (not current user) and this is understandable because UAC creates a second process for installer and runs it again. And I get the same result - the program's installed for Admin user :)

BTW, UAC has its Logon dialog and it may confuse "more advanced" users.

Anders
27th February 2009 01:42 UTC

ShellExecuteEx with runas does in fact return the process handle, and you can wait on it.

as far as the uac plugin goes, what you are looking for is UAC::ExecCodeSegment, it will execute a nsis function as the user, not the admin

I don't know what login dialog you are talking about, the UAC plugin just does ShellExecuteEx with the runas verb in 99% of system configurations

ksngs78
27th February 2009 01:55 UTC

Originally posted by Anders
ShellExecuteEx with runas does in fact return the process handle, and you can wait on it.

as far as the uac plugin goes, what you are looking for is UAC::ExecCodeSegment, it will execute a nsis function as the user, not the admin

I don't know what login dialog you are talking about, the UAC plugin just does ShellExecuteEx with the runas verb in 99% of system configurations

Anders
27th February 2009 02:04 UTC

I'm the author of the UAC plugin, so I know how it works...

It will use the OS runas unless the major version >= 6 and UAC is off (In this configuration, UAC does not elevate so I have to roll my own solution)