admin limitations on Vista?

I have small application (sorry, download is fast inside Russia only, but package is 120 kB, thanks NSIS 🙂 ). The problem is following: on Vista when application starts first time from installer' finish page with admins privilegies from installer as child process (installer running with RequestExecutionLevel or not - both cases Vista displays UAC and elevates level to admin, installers auto-recognition feature), it not gets drag-n-drop messages and some other communication messages as well. The same happen if I start it with 'run as administrator' option later. But if I simply launch it from desktop or start menu icon (execution level 'user', admin not required) all works correct. This behavior not depends on current (start) folder. Brief google search not gave me any good links..

It's called User Interface Privilege Isolation. More information about this is available in MSDN.

Thanks, kichik! Nice feature... I added manifest with asInvoker, but this not helped. The only way I see now is to remove 'Run' checkbox from finish page and ask user to start program manually 🙁 But user still can run application as admin.

There's some code to handle this in another forum thread:



Andres also wrote a plug-in, I think.

Thanks again, sometimes forum search is better then google 🙂

You can try the SAFER plugin.

Use MUI_FINISHPAGE_RUN_FUNCTION and call the safer plugin with SAFER_LEVELID_NORMALUSER level.

SAFER::Exec NORMAL "$instdir\\myapp.exe" 

If your installer supports pre XP versions you should call SAFER::SupportsSAFER and just use normal Exec if the SAFER api is not supported

Thanks, Anders! I not tested it yet, but looks interesting. And I have feature request for 0.2 version 🙂 Now I should write 3 or more lines of code:

if(supportsSafer)
  SAFER::Exec NORMAL "$instdir\myapp.exe"
else
  Exec "$instdir\myapp.exe" 

Is it possible to do it all in a single call (CreateProcess() if no entry points in dll) and keep my brains for other fun 😉 ?

thats what macros are for, something like:

!macro ExecSAFER _level _cmdline
SAFER::SupportsSAFER
StrCmp $0 0 +3
SAFER::Exec ${_level} '${_cmdline}'
Goto +2
Exec '${_cmdline}'
!macroend
!insertmacro ExecSAFER NORMAL 'calc.exe' 

Tested. With SAFER token program fails to open file for write in $INSTDIR. I'll think later if I can use appdata folder for this file, but if I stop program and start it again - all works correct (can write file).

!insertmacro ExecSAFER NORMAL "$INSTDIR\${APP_EXE}"

IDEA:
1) Copy a manifest document were level is asInvoker (asInvoker is the new term on Vista versoin >=Beta2) to the application directory where the application resides you want to start.
2) Start the application
3) Delete the manifest document

NOTE:
(XML data is called a "XML document", not "XML file")

2 onad:
I wrote about this in my second post 🙂
Not works 🙁
Looks like child thread inheritation priority is high then manifests (while I not tested embedded manifest, but file priority is higher).

There's an article on MSDN that suggests bootstrapping the installer with another application that'd run as the user and will later also execute the installed application. I really hate this method, but it does work.

Originally posted by Takhir
Tested. With SAFER token program fails to open file for write in $INSTDIR. I'll think later if I can use appdata folder for this file, but if I stop program and start it again - all works correct (can write file).

!insertmacro ExecSAFER NORMAL "$INSTDIR\${APP_EXE}"

A normal user cannot write to ProgramFiles so im not sure why it works if you start the program manually

I tested program with app data folder. Launched from installer it could not write to application data/company/prog_name as well. The only place where it could was GetTempPath(). I can use tmp folder for this file, but program saves other (user's configuration) file to app_data, so this is a problem. File is too big for registry (access to registry works correct)..

Anders, you can write there because of Vista Virtualisation, this is a kind of backwards compatibility layer on Vista to solve problems with "old" software.

IDEA1)
Do a run dll of an INF file there you can add an RUN entry, since the INF format description as not fully made public by MS this can be difficulult

IDEA2)
As menationed before a bootstrap application which starts the installer with admin privileges and if finished starts another app with regular priviliges

IDEA3)
Downgrade the options of the running process, hmmm

IDEA4)
Set app compatibility flag to W98, test if works?

IDEA5 ??)
Tell it to us please, be creative in thoughts....

What about CreateLowProcess from MSDN. It looks promising, as long as you can find out the SID for the medium integrity access level. There's code a page below CreateLowProcess that retrieves the current integrity access level. It can probably be used from a normal process to get that SID.

Looks like SAFER is a wrapper for this as the terms are pretty similar, but who knows... I have to get myself Vista access again 🙁

You can inspect the process token SAFER creates with process explorer, its probably not the exact same thing as running the program manually

There is another way to start a program non elevated on vista, documented @ http://www.tweak-uac.com/programming/vista-tools/ (RunAsStdUser) I dont have Vista so I can not test or implement it