Archive: SetShellVarContext user


SetShellVarContext user
Hi all,

I'd like to know if it is possible to set : "SetShellVarContext current" when I need to execute the installer with admin rights (but from an "normal" useraccount).
The Problem is, when setting "SetShellVarContext current" and executing with admin privilegs the $SMSTARTUP (for example) is the Startup dir of the admin and not the one of the user, who executes the installer with admin rights.

Is there a sollution for this Problem?

Thanks in advance,

Omid


check out the UserInfo plugin (comes with NSIS). With it you can get the original user account credentials as well as the current user account credentials. That way you can detect that a User has 'Run As' your installer as admin (or elevated via UAC in Vista).

How to go from there, though... not sure.


Originally posted by Animaether
check out the UserInfo plugin (comes with NSIS). With it you can get the original user account credentials as well as the current user account credentials. That way you can detect that a User has 'Run As' your installer as admin (or elevated via UAC in Vista).
that is not true, UserInfo does not give you that info. UserInfo can tell you if the current PROCESS or current USER is a member of the admin group or whatever, but its not related to UAC at all, its related to Deny Group SID on a Token (talking about GetAccountType vs GetOriginalAccountType here)

anyways, you can use the UAC plugin to pull this off, but you should understand that doing this is not "correct". If your script contains RequestExecutionLevel admin, then you are doing a "all users" install and you should only use SetShellVarContext all

hurr.. so that only works the other way around; admin with the installer requesting level 'user'?
(
# On Vista with UAC, for example, this is not the same value when running
# with `RequestExecutionLevel user`. GetOriginalAccountType will return
# "admin" while GetAccountType will return "user".
)


@Animaether: It has NOTHING to do with UAC, forget about it. You will see it on XP if you right-click and choose run-as, then check the protect my computer option (NSIS does not even run with it checked IIRC, but thats another story) The protect my computer option uses the SaferAPI behind the scenes, so it applies to others using that API also, or if they are building a token by hand and adding deny SID's on their own

Try using my SaferAPI plugin and check the security tab of a process in Process Explorer, run the nsis app as admin, look at its child spawned by the safer api, it will have a DENY Admin SID in its process token (or http://www.devdebug.members.winisp.n...dd9e97b9_o.png if you are lazy)

Older versions of the UserInfo plugin will report someone with a deny admin SID as admin, that function now has Original in the name and the other function calls the correct api on 2000 and later and is able to handle deny SID's

For more info:
http://blogs.msdn.com/aaron_margosis...10/227727.aspx
http://msdn.microsoft.com/en-us/library/aa446583.aspx
http://blogs.msdn.com/larryosterman/...51.aspx#225519


slightly misleading in the user info example, then - thanks for the info, Anders - will peruse :)


thanks guys for your responds.
I will do the installation for all users.

regards,

Omid