views:

630

answers:

5

Environment.SpecialFolder.CommonApplicationData

*returns "C:\Documents and Settings\All Users\Application Data" under XP that is writeable for all users

*returns "C:\ProgramData[MyApp]\" under Vista and this is not writeable for regular users

Now why i want CommonFolder ? Because, an admin will install my software database on XP (or vista) under Admin account, but when user logs back and run my software, the current account will tel my software to look at a different place the database was installed : the user directory in Documents and settings....

so AllUsers (common folder) is common to admin and regular non admin user..

This drives me crazy : where to put my database so it works under Vista and XP ????? thanks Jonathan

+1  A: 

Vista is set up such that files saved from one user's account cannot be modified from another user's account. This enforces isolation between one user account and another, as well as protects settings/files that affect the state of the entire system.

Your program should indeed install whatever machine-wide state it needs in ProgramData at install time - this folder is shared between all user accounts; however, it is a read-only type of shared . Administrator privileges are needed to modify these files if the current user did not create them because they affect the entire computer, not just the current user account.

In accordance with this policy, the security on the ProgramData folder is as follows:

System: Full Control over files & folders Administrators: Full Control over files & folders Creator/Owner: Full Control over files & folders Users: Read Only for files, but can create new folders and files

What this accomplishes is that it allows any user to read and create a folder/file anywhere inside the ProgramData folder, but the user can only modify the files that were created from their user account; they cannot modify files created from another user account.

The only exception that I know of to this policy is the c:\users\public folder, which is designed to allow users to store documents and such that they want to be world read/writable.

From here. Looks like someone else had the same problem.

ryeguy
you're right. Same issue ! but i don't see clear answer
+4  A: 

User-specific settings should be stored in the User's application data folder (Environment.SpecialFolder.ApplicationData) , so that if multiple users log in to the machine they each get their own settings. Create a default user-settings db for the program in the program's main folder at install time and copy it to a user's folder the first time that user runs the program (you'll know it's the first time because the db file won't exist yet).

If you have settings that should apply to all users on the machine, you want those settings to be set by an administrator, and you want them protected from casual change. Storing these in a place where normal users don't have write access is a good thing.

Joel Coehoorn
ok, but how do you deal with an admin that makes an install, and the user that runs the software afterward ? My program will not find the database created during admin install
Your program should create a db for the user the first time they run it. Anything that applies to all users needs to be set by an administrator.
Joel Coehoorn
hum, the db is not empty at first install...
You need 2 dbs: one for machine-wide settings to hold things that users should NOT change (like connection information, license information, etc). The other to hold user-specific settings (profile information, preferences, etc).
Joel Coehoorn
+1  A: 

Can you make use of the IsolatedStorageFile.GetMachineStoreForApplication and IsolatedStorageFile.GetUserStoreForApplication methods?

My apologies if I have misunderstood your question.

ZombieSheep
+1  A: 

Are you using an installer to have the admin run? If so, you should be able to use the installer settings, plus a proper assembly/executable manifest to allow the application (regardless of who is running it) the proper permissions to update/modify files in the ProgramData specific to their application.

I run a similar scenario (application installs to Program Files, common data repository installs to ProgramData, user config,save files store to C:\Users) and the manifest and the settings in the WiX installer allowed this to work.

Dillie-O
i think what you say sounds right. Now i use NullSoft installer... I don't know wix. Do you use it for .net program ? what is its advantage ?
Yes, I use it for two .NET based WinForms applications. The main advantages I found was that it is free and uses an XML schema for all of the settings, and has a lot of flexibility. It also has the option to be a project in your solution so a full build rebuilds your setup file too.
Dillie-O
i see and how do you set the permissions ?
Creating the .manifest (another XML based document) file will have a section where you indicate the permissions application. Similarly there is a section in your WiX config file that indicates the necessary permissions for user/groups within the folders you specify. Documentation exists for both.
Dillie-O
One thing to note, the .manifest file is seperate from WiX, it is something specific to .NET for application deployment/security and is necessary for Vista.
Dillie-O
A: 

where to put my database so it works under Vista and XP

If this database is a SQL Express data file or other shared resources it needs to be in a loocation that the server process's account can read/write.

returns "C:\ProgramData[MyApp]\" [corrected typo] under Vista and this is not writeable for regular users

Not according to a quick check at the ACL here (actually Win2k8):

PS C:\ProgramData> get-acl . | select -expand access

[...]

FileSystemRights  : ReadAndExecute, Synchronize
AccessControlType : Allow
IdentityReference : BUILTIN\Users
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : Write
AccessControlType : Allow
IdentityReference : BUILTIN\Users
IsInherited       : False
InheritanceFlags  : ContainerInherit
PropagationFlags  : None

Note the last to ACEs, normal users do have write access, but only to folders and the files they contain, not to files directly in C:\ProgramData.

However if a user creates a folder in C:\ProgramData then other users will not have write permissions.

Answer: Create folder under ProgramData for your database, and set the ACL on that folder to give all users read & write access to files in that folder.

Richard
can i do that during install ?
Yes, ability to set ACLs is pretty fundamental to an installer.
Richard