[wpkg-users] Run script in elevated mode

[Daniel Dehennin]

Rainer Meier <r.meier at wpkg.org> writes:

> Hi Daniel,

Hello,


> Probably you just need to verify the paths. If I am not mistaken INSTALLER_LOC
> is set to "%~dp0" which means it points to the path from which you call
> install.cmd. So you need to make sure that the script called
> ("%INSTALLER_LOC%%INSTALLER%") is stored within the same directory. If it's not
> you need to change the path to the installer (unattended.cmd).

It's ok, I have a copy of unattended.cmd on each installation folder, so
I can copy it to an USB key and run install.cmd on a non WPKG computer.

>
> Please also keep in mind that if you run an elevated command this command will
> run with different user credentials. Make sure that you're providing access to
> the elevated user to the share as well.

That's strange, I only need this on non WPKG computer as I use WPKG
client, when running elevated commands I do not need to type a
login/password, just to confirm with the OK button.

It seems finally that I need to open a new connection in the elevated
sub-command.

I made some tests to run %ComSpec% in elevated mode:

1. Right clic -> run as administrator with the following script
===
@echo off

start /wait "elevated" %ComSpec% /c "echo TEST > %TMP%\result.txt"
===

- I need to confirm the elevation (UAC)
- the window open and close immediatly, the result.txt contains
  (approximately translated): "No such file".

2. Using execute-elevated.js with normal double clic:
===
@echo off
start /wait "elevated" cscript /Nologo execute-elevated.js %ComSpec% /c "echo TEST > %TMP%\result.txt"
===

- I need to confirm the elevation (UAC)
- the window open and close immediatly, the result.txt contains: "TEST"

I tried with "net use" to see if my open connection is here:
start /wait "elevated" cscript /Nologo execute-elevated.js %ComSpec% /c "net use > %TMP%\result.txt"

- the result.txt contains (approximately translated): "empty list"

So I can not run my cmd scripts from a network share, great :-/

>> I put "echo DEBUG > %TMP%" at the top of unattended.cmd and see that
>> nothing is created, so the script is not called.
>
> Probably because either the path is wrong or the elevated user does not have
> access to the share.
>
> Unfortunately you did not express your use-case. Usually it's much more
> convenient to just run wpkg.js elevated so its elevation is inherit by
> sub-processes. If you use execute-elevated.js for individual packages you would
> have to provide credentials for each single package. Here it's usually not even
> required to use execute-elevated.js since you will be able to run wpkg.js
> unelevated and installers will usually ask for elevation as needed (unless
> Windows does not recognize the installer and it misses a proper manifest).

I only need this for non-WPKG computers, I have an install_computer.cmd
which run a list of cmd scripts to install the bare applications on a
computer, I thought I could :

- open a connection to my server (run -> \\myserver)
- on my install_computer.cmd: right clic -> run as administrator

The idea was (in the install_computer.cmd) :

- test if I am in elevated mode (I don't find how to test it)
- if not, call myself wrapped in execute-elevated.js (cscript
  execute-elevated.js %0 %*)
- call all the needed cmd scripts which inherit elevated mode (as far as
  I understand)

I can not expect the system to do the right thing, I run pre-post script
with my unattended.cmd (an improvement of your install.cmd ;-)) to
add/remove some registery keys, remove some folder for application which
let some after uninstall, etc.

I tried to use runas with /trustlevel but I did not manage to use it :-/

If someone have an idea, for now it seems that I need to copy everything
locally and run from here :-/

Regards.
-- 
Daniel Dehennin
RAIP de l'Orne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20100311/757f18b7/attachment-0001.sig>