Standard User Setup Catch 22

[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

 

[jimmuh]

Tell the guys who wrote the software to make it Vista-compatible?



I know this is frustrating. If there aren't other issues with the software I
guess you could make the user account an admin type, install the software
from that account, then change the account back to standard user type.

Annoying, but (probably) effective.

 

[Max Plank]

Tell the guys who wrote the software to make it Vista-compatible?



I know this is frustrating. If there aren't other issues with the software I
guess you could make the user account an admin type, install the software
from that account, then change the account back to standard user type.

Annoying, but (probably) effective.

I guess the question is how to make a setup program Vista compatible
given this catch 22. That is:

* A setup program needs administrator privileges in order to write
files to the Program Files & System32 folders.

* When running with administrator privileges, the call to
ShGetFolder(CSIDL_LOCAL_APPDATA) doesn't return the standard user's
local appdata folder.

 

[Kerry Brown]

I guess the question is how to make a setup program Vista compatible
given this catch 22. That is:

* A setup program needs administrator privileges in order to write
files to the Program Files & System32 folders.

* When running with administrator privileges, the call to
ShGetFolder(CSIDL_LOCAL_APPDATA) doesn't return the standard user's
local appdata folder.

User data shouldn't be created during the install. It should be created
during the first run of the program by each user.

 

[jimmuh]

My apologies. Upon re-reading your original post it's apparent that you
weren't approaching this from the end user's perspective. I guess Kerry Brown
has the idea. I would only add that many installation processes ask at their
terminus if the user would like to launch the software upon completion of
setup. This also results in creation of user data in the "wrong" location.

I shall now dope slap myself and retire to stare into my corner.

 

[Kerry Brown]

My apologies. Upon re-reading your original post it's apparent that you
weren't approaching this from the end user's perspective. I guess Kerry
Brown
has the idea. I would only add that many installation processes ask at
their
terminus if the user would like to launch the software upon completion of
setup. This also results in creation of user data in the "wrong" location.

It shouldn't matter though. Other than the user being annoyed at setting up
the user settings twice they should still get the user setup portion the
first time the program is run in the context of their account.

 

[jimmuh]

That's true, except when the software manages to continue to try to use the
wrong (admin) profile even when run from the regular user profile. I've seen
several instances of this, especially in malware detection software. In one
notable instance you wind up always writing log files to a location under
Documents in the original profile from which the software was run, regardless
of which profile you start it from later on. Ugh.

 

[Max Plank]

User data shouldn't be created during the install. It should be created

during the first run of the program by each user.

That is how I've always handled it, but 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

###

 

[Ronnie Vernon MVP]

Max

Are you including a Manifest file with the application? Here are some links
that are recommended if you are developing applications for Vista.

Go here first for a quick overview on this subject.
Windows Vista Application Development Requirements for User Account Control
(UAC):

http://msdn2.microsoft.com/en-us/library/aa905330.aspx


Download the following document. This includes a complete discussion of the
subject including code examples. Windows Vista Application Development
Requirements for User Account Control Compatibility:

http://tinyurl.com/2pf8n3


There is also a very comprehensive help file that deals with the subject of
developing applications for a least privilege environment that you can
download here:

http://tinyurl.com/2uh8ve