Vista Security Issues after Install

[Doug I]

Hi,

When my Vista customers install and launch the program immediately after the install, all is fine.

Once the user exits my program and re-runs the application, my program fails to run as a result of Read/Write Issue in the program folder (i.e. Vista not allowing database write access to the newly created folder). Manually going to Vista's Explorer, selecting the program folder, and changing the security settings by selecting Full Control on the user group, fixes the problem.

Is there some script code within SB that I can add that will identify the OS as Vista and make the appropriate folder security changes during the install process?

Thanks in Advance.

[Charles J. Edmonds]

Welcome to Vista!

I don't think your having a folder permission problem as much as you might be having a folder location problem.


If your installer is running in elevated status (as it most likely is) and you allow the user to launch the program at the end of the install - then the program is creating folders, writing HKCU entries, etc as the "Administrator" - not as the "User".

Then when the program is ran the next time (under Vista all programs are ran as the "User" - even if they are logged in as the "Administrator") your program is looking for folders, Registry entries in HKCU, etc in the "User" space.

In general the solution for this is to NOT run the program at the end of the install.

This is just the way things work under Vista and short of some hacks using the scheduler to delay the launch of your app until the termination of the installer occurs (and the status drops to the "User" level), there is not much you can do.

Does this help?

Charles

[linder]

Hi Charles,

Couldn’t have said it better… ;)

And Dogh, you should *never ever* change the access permissions on Program Files folders or sub-folders!

Friedrich

[Doug I]

Thank you both for clearing up the Vista issues.

But maybe you could clear up one or two last things on this subject:

1. Are you suggesting that by not allowing the SB installer program to launch the application at the end, the security rights problem I am encountering would not occur?
The way I am understanding your explanation, the first time the application is run, the security rights are set according to whether its Admin or User rights.
By not running at the end of the installation process and forcing the user to click on the newly created desktop icon from SB, the proper User Security rights will kick in with the appropriate registry changes and not cause my read/write problems on subsequent revisits to the application. Correct?

2. Can I dynamically tell the SB installer script to not show the checkbox option which launches the application if it is running under Vista?
Is this the best approach to this issue or are there better techniques for installing a Win32 database app on a Vista PC which will avoid these security issues?

Thanks In Advance.

Doug I

[Charles J. Edmonds]

Thank you both for clearing up the Vista issues.

But maybe you could clear up one or two last things on this subject:

1. Are you suggesting that by not allowing the SB installer program to launch the application at the end, the security rights problem I am encountering would not occur?
The way I am understanding your explanation, the first time the application is run, the security rights are set according to whether its Admin or User rights.
By not running at the end of the installation process and forcing the user to click on the newly created desktop icon from SB, the proper User Security rights will kick in with the appropriate registry changes and not cause my read/write problems on subsequent revisits to the application. Correct?

2. Can I dynamically tell the SB installer script to not show the checkbox option which launches the application if it is running under Vista?
Is this the best approach to this issue or are there better techniques for installing a Win32 database app on a Vista PC which will avoid these security issues?

Thanks In Advance.

Doug I


RE: #1

It is hard to say without knowing exactly what your app is doing, but let me give you some ideas.

First off, in order to be Vista compliant - your program should not write ANYTHING to a location under the "Program Files" folder (which is where I assume your installing to). If it does - then Vista will treat your program as a "Legacy" application, start "virtualizing" where the data or settings are written ... and you are in hell<vbg>.

Likewise also FORGET about writing anything into the Windows folder. Now that Vista is here - those days are over<g>.


This means that your program should be using a different folder (such as under My Documents or Common Documents) for the data and the recommendation is to use the Registry to store program settings.

You also need to consider if the database will be single user or shared.

If shared, your best bet is to install it under Common Documents - otherwise under My Documents (or in some cases AppData)


Next your app will need to know where the data is.

Your best bet to do this with the SetupBuilder ability to use CSIDL that identifies standard folder locations (thus it becomes OS version independent) and then storing those in either a Registry entry or an INI file.


Now - for user specific settings you would normally store those in the HKCU Registry hive in something like:

HKCU\My Company\My Program\DataDir


What I do is have SetupBuilder write a entry in the HKLM Registry hive in something like:

HKLM\My Company\My Program\ProgramDir


Then when the program runs it knows where the program is installed.


Next (in my case) when the program first runs, it creates the data directory and database files under My Documents in something like:

My Documents\My Program

and it writes settings to the Registry in:

HKCU\My Company\My Program


(( sound confusing yet? ... hang in there - it is not too bad! ))


Here is the key to understand the relevance of all this:

The CSIDL that identifies the "My Documents" folder location (or the HKCU Registry location) for the user is based on the User Name as identifed by Windows.


When your program is installing (in elevated status) - that user name is typically "Administrator".

But as soon as the install is complete and you run the program as yourself - you are "Doug" (even though you might BE the Administrator)...

The CSIDLs for "Administrator" and the one for "Doug" are not the same!


If your program "runs" at the end of the installer - the program will look to the "Administrator" locations and create databases or store settings there.

Then when you run the app the next time as "Doug" the program is lost and can't find or access the data.

If you wait and run the program AFTER the installer is all done, the "Doug" is "Doug" and the data is created in the "Doug" space and the next time you run it - it can still find it.

Does that make sense?

;)



RE: #2

Yes you could do it that way by checking the OS version in the script.

However if your not supporting OS's older than Windows 2000, you could just adapt your program and installer to use CSIDL locations there too.


You have to evaluate your own program and decide which way it is easier for you to support.

Most developers hate making the transition to using the suggested data locations and follow Microsoft guidelines and practices for this, but IMHO - the sooner you adopt them the better off you will be.

If your not already using them - then that is most likely the reason your having problems here.

So it only makes sense to take a little time and solve the problems now (once and for all) and your program will be "ready" to run with the next Windows version too.

Proper use of the CSIDL technology and a little bit of planning and adaptation of your app means you can just install without having to fight every step of the way.


Does that help?


Charles

[linder]

Doug,

Exactly what Charles said.

BTW, we are using the following to not display a Run option at the end of the installation. One Finish dialog has the Run option, the other one does not.

Does this help?

Friedrich