Passing variables back from an outer process using UAC plugin

NB-Dexter
21st November 2008 13:55 UTC

Passing variables back from an outer process using UAC plugin
While you can send data in to a user level process using UAC::ExecCodeSegment, I have a need to get parameters back, for example I needed to know the acccount name of the user level account for some settings that are done from the inner, admin level process.

The solution I came up with is using a temporary .ini file that both processes can see. I couldn't use $TEMP because the inner and outer processes don't get the same folder. I couldn't use a registry key because I didn't know the user account for HKCU of the user process. I ended up using $APPDATA with SetShellVarContext set to "All". This gives a consistent path in both user and admin processes on XP and Vista.

Here's an example:

Function UserTest

MessageBox MB_OK "User Privs process$\n$\nReceived value from Admin process: R1 = $R1"

SetShellVarContext all
strcpy $R1 "From user"
WriteINIStr $APPDATA\temp.ini "RegVal" "R1" $R1

FunctionEnd

[Section code after UAC::RunElevated]
.
.
.
strcpy $R1 "From admin"
MessageBox MB_OK "Call UserTest with user rights. Sending R1 = $R1"

GetFunctionAddress $R0 UserTest
UAC::ExecCodeSegment $R0

; Get changed R1 value

SetShellVarContext all
ReadINIStr $R1 "$APPDATA\temp.ini" "RegVal" "R1"
MessageBox MB_OK "After call to UserTest with user rights. R1 = $R1"
.
.
.

Make sure you remove temp.ini when you're done with it. Probably be better to create a folder in APPDATA but, you get the idea.

I hope this is of help to someone. I've struggled with this off and on for awhile now.

ianamason
2nd January 2009 21:08 UTC

Indeed it has helped someone. What worries me with this
scheme, though, is the following quote from the manual
entry for SetShellVarContext:

Please take into consideration that a "normal user" has no rights to write in the all users area. Only admins have full access rights to the all users area.

Has this bitten you ever? Do you worry too?

Cheers, Ian.

Anders
2nd January 2009 21:30 UTC

v0.0.11 of the plugin added UAC::GetShellFolderPath so you can get the path to the profile (and the other CSIDL paths) of the "normal" user

NB-Dexter
2nd January 2009 21:57 UTC

Originally posted by ianamason

<snip>
.
.
.
Has this bitten you ever? Do you worry too?

Cheers, Ian.

I tested this on XP and Vista and did not have any issues. My standard user account was able to write to the appdata folder with setshellcontext set to all. Did you try it?

Originally posted by Anders
v0.0.11 of the plugin added UAC::GetShellFolderPath...

Sweet, I'll have to check that out.

Anders
2nd January 2009 22:03 UTC

its not on the wiki yet, grab it from http://stashbox.org/tag/nsis for now

NB-Dexter
2nd January 2009 22:16 UTC

Thanks, I noticed the wiki still had the old one and was just about to ask where I could find it. This will make my solution a little cleaner.

ianamason
2nd January 2009 22:25 UTC

NB-Dexter: Yes I am testing on a vista business box, and it
works fine. But who know where it would bite?

Anders: Excellent, I'll futz with that asap.

Again, thanks to both of you.

abarinoff
7th April 2010 09:52 UTC

I've described the solution for original thread's problem in following post: Passing parameters and retrieving results from inner/outer UAC processes in NSIS-based installer

MSG
7th April 2010 14:09 UTC

Errr... Isn't that way out of date? The UAC plugin syncs registers both ways. Using a file to write/readback the result is definitely NOT the way to do it...

Anders
7th April 2010 14:54 UTC

only the new version syncs both ways