User Account Run Setup Catch 22

  • Thread starter Thread starter Max Plank
  • Start date Start date
M

Max Plank

Greetings,

Does anyone know a workaround for the following catch 22:

* From a Standard User Account under Vista, a user runs a setup
program to install an application.

* The setup program requires Administrator Privileges in order to run
and displays the admin password dialog. The admin types in the
password and the setup program proceeds with installation.

* During the installation, the setup program queries for the
CSIDL_LOCAL_APPDATA folder location in order to create folders and
install per-user files there. Since the setup program is running with
administrator privileges, the folder location returned is the
administrator's CSIDL_LOCAL_APPDATA folder, not the user's.

TIA
 
Does anyone know a workaround for the following catch 22:
* From a Standard User Account under Vista, a user runs a setup
program to install an application.

* The setup program requires Administrator Privileges in order to run
and displays the admin password dialog. The admin types in the
password and the setup program proceeds with installation.

* During the installation, the setup program queries for the
CSIDL_LOCAL_APPDATA folder location in order to create folders and
install per-user files there. Since the setup program is running with
administrator privileges, the folder location returned is the
administrator's CSIDL_LOCAL_APPDATA folder, not the user's.

TIA
Click to expand...

One workaround would be to log in with an Admin account and temporarily make
the Standard User a local admin. Log in with that account, install the
software, and when you're done reduce to user's privileges. I used to do
this on XP because it was common for software installs to fail when using
the "Run As" option with Admin credentials.
 
One workaround would be to log in with an Admin account and temporarily make
the Standard User a local admin. Log in with that account, install the
software, and when you're done reduce to user's privileges. I used to do
this on XP because it was common for software installs to fail when using
the "Run As" option with Admin credentials.
Click to expand...

Thanks - I guess I wasn't really looking for a workaround - poor
choice of words on my account.

Further research has edged me closer to a solution, but not there
yet. Here's what I've got so far:

When testing from a Standard User account, I find that folders and
files created under Vista by an installer running with administrator
privileges cannot be accessed (not even copied) by a program running
"asInvoker" from a Standard User account.

From what I (poorly) understand at this moment, the key is for the
installer to grant ACL permissions to any folders/files created during
the setup process so they can be accessed later by the program running
asInvoker under a standard user account. I'm hoping it's merely a
question of the installer calling SHGetFolderPath() with the proper
htoken:

http://msdn2.microsoft.com/en-us/library/bb762181(VS.85).aspx
htoken: An access token used to represent a particular user. This
parameter is usually set to NULL, in which case the function tries to
access the current user's instance of the folder. However, you may
need to assign a value to hToken for those folders that can have
multiple users but are treated as belonging to a single user. The most
commonly used folder of this type is Documents.

Some references to the problem and potential solution:

http://www.msdner.com/dev-archive/89/24-113-898420.shtm
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2276841&SiteID=1
http://msdn2.microsoft.com/en-us/library/ms717798(VS.85).aspx
http://technet2.microsoft.com/windo...2517-4e7a-ba39-d37c8b8202e31033.mspx?mfr=true

###
 
Back
Top