On Window 7, 8 and 10 I want my app to store data in shared location so all users who run the app on the PC will access the same data. The data are readable/writable. What location should I use?
Windows has funny rules regarding program' shared data.
Program Files ("C:\Program Files" and "C:\Program Files (x86)") is intended for immutable (read-only) program data and executable files - consequently files here require administrative permissions to edit. Thus it makes it useful for important files that should not be compromised (e.g. your main executable). This is why installers run with elevated permissions. There is a downside in that if your program has an auto-update mechanism then that too needs to run elevated.
Program Data (C:\ProgramData on Windows Vista and later, or C:\Documents and Settings\All Users\Application Data) is intended for mutable program data - you don't need administrative permissions to create files in this folder, except that once a file has been created only the user that originally created that file can subsequently edit it (though everyone can read it). This is the special CREATOR OWNER permission.
This is described here: Privileges/owner issue when writing in C:\ProgramData\
AppData (C:\Users\(you)\AppData\Local and C:\Users\(you)\AppData\Roaming) is user-specific and is intended for user-specific settings, configuration and data. The Local version should be used for machine-specific settings that shouldn't roam if the user is using Roaming Profiles, such as data caches (e.g. a browser cache).
So in your case ProgramData looks ideal, but you need to be careful about the default CREATOR OWNER rules - but there's a workaround: your program's installer (which would run as admin) has the ability to change the ACL permissions on its ProgramData subdirectory to allow other users to edit files. I suggest granting the Users group permission instead of Everyone to prevent possible remote attacks and modifications by unauthenticated users.
Related
I have a visual studio setup project which installs my files to the program files folder and also writes some stuff into the registry and in addition some of the files are com visible (so there is more confusing stuff written to the registry).
Therefore I have to install it as an administrator - this works fine. And this administrator and every other administrator is able to start the program. But using a standard user I am not able to start the program.
All registry entries are there for the standard user - and it also has enough rights to access the file in the Program Files folder.
Could there be a problem with the ComVisibility? (Which is needed because it's actually a DLL working as a plugin for Solidworks)
You just need to look at the code in your app and see what it does that limited users can't do. Installing it for all users does not mean that it automatically allows limited users to violate security. Just find out what it's doing when it gets the security error (which is what you believe it is).
Limited users have never been able to write to restricted areas such as the ProgramFiles folder, CommonFiles folder, HKLM etc. That's a common reason for limited user issues with apps.
My application updates some registry fields related to licensing under HKLM. This is for accessing the information for all users in the system. This makes us to make our application run as administrator. Is there any other location in registry where I can keep information which can be accessed by all users?
Registry HKLM and folder %ALLUSERSPROFILE% are accessible to all users, but meant for writing to at install time (as admin).
Registry HKCU and folder %APPDATA% are accessible to current user and meant for writing to at any time.
Why are you modifying licensing info (shared by all users) during run and not just during install?
You could place as an (e.g.) XML document in the file system under a shared folder instead of the Registry.
E.g. System.Environment.SpecialFolder.CommonDocuments or CommonApplicationData.
No there is not. If you have to make a modification that will affect/be visible to all users, you have to deal with UAC or elevate your application on startup. This is part of the design of UAC. If, however, you were to write to a file you could grant all users access to that file without UAC interference.
If, however, you are only reading the registry, you can do this without elevating your security rights. Therefore, if you write once to the registry and then just read it later, you can do so when only elevating your privileges once.
Here is an article on playing nice with UAC:
http://msdn.microsoft.com/en-us/magazine/cc163486.aspx
I'd make your installer precreate the registry entries (it runs as admin typically), and open up their permissions using GetSecurityInfo and SetSecurityInfo. Then your app can write to them without any special perms.
I know that commonappdata (All Users) can hold system-wide application settings, but under Vista/7 non-elevated users can't write to that directory.
Is there a folder which is shared among users and any non-admin user can write to it?
Here is why I need this:
My app is installed in PF directory by an Inno Setup installer with elevated rights. Then when the actual non-admin user runs the program, it copies its settings to the user's AppData directory using another non-elevated Inno Setup installer. Upon deinstalling the program (initiated by the system-wide installer with admin rights) I want to uninstall the program's files from each users' AppData directory.
I can think of two solutions:
1. Getting a list of Windows users and iterating through their AppData dirs (seems way too complicated)
2. Storing the paths to the uninstallers in the above mentioned common user data directory.
Any ideas?
Thanks!
"Shared Documents" Directory in Windows XP
C:\Documents and Settings\All Users\Documents
Or,
%ALLUSERSPROFILE%\Documents
Corresponding directory in Vista/7
C:\Users\Public
Or,
%PUBLIC%\Documents
But what you are really looking for, is the KNOWNFOLDERID value of FOLDERID_PublicDocuments (legacy CSIDL_COMMON_DOCUMENTS). The SHGetFolderPath function can then get you the path.
Or an easier VBScript alternative, but I'm not sure how reliable this is across OS versions:
Const CSIDL_COMMON_DOCUMENTS = &h2e
Set oShell = CreateObject("Shell.Application")
Wscript.Echo oShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path
I think NameSpace doesn't accept that particular constant. So you might be able to take COMMONAPPDATA = &H23 and then use its parent. But that's not very clean or internationalized:
Wscript.Echo oShell.NameSpace(&h23).ParentFolder.Self.Path & "\Documents"
But since you are using Inno Setup, you should really be using the {commondocs} Shell Folder Constant and make it easy for yourself.
The user owns the document folder. Expect files to be copied, moved, deleted or edited with another program if you put something there, because of the visibility to the user.
I suggest you to create a folder under the common application data (CSIDL_COMMON_APPDATA or FOLDERID_ProgramData) in your installer with a security descriptor that allows everyone access.
E.g.
[Dirs]
Name: "{commonappdata}\productname";Permissions:everyone-modify;
Would stuff under C:\Users\Public\ qualify for what you need?
Solution 1 looks quite reasonable to me. So every user control their and only their installation, and you control the central shared installation.
For solution 2 you can create a write-allowed folder in a well-defined location so that your installer knows about it, or use a registry key for the same purpose. But keep in mind that this may create a security hole because anyone could tamper with uninstall paths of other users.
Until Windows Vista I saved my application data into the directory where the program was located. The most common place was "C:\Program Files\MyApplication". As we know, under Vista and later the common user does't have rights to write under "Program Files" folder.
So my first idea was to save the application data under the "All Users\Application Data" folder. But it seems that this folder has writing restrictions too!
So to sum up, my requirements are:
The folder should exist under Windows XP and above.
All users of the system should have read\write\creation rights to this folder and its subfolders and files.
I want to have only one copy of file\files for all users.
It's often good to use environment variables so you keep things more generic.
Vista has changed some things, with NTFS Junction Points. See http://www.svrops.com/svrops/articles/jpoints.htm
Anyway, using %appdata% should automagically put files in the proper place on xp/vista/7
There is no such location. Even on Windows XP (and probably 2000 as well) no such location ever existed; we just think it did because we all ran with administrative privileges. It is not until Vista forces us to run as limited user that we realize our incorrect assumptions. You're going to have to explicitly set the permissions on your directory.
I would create a subfolder like All Users\Application Data\YourAppName\Shared, so that it's clear that just that folder will contain files writeable by all the users, setting up the privileges in the installer.
I'm building a product that involves
a windows service caching data on the local machine,
user processes reading that data and writing their own data,
the service in turn writing back that data to a server.
Where should I put the data files for this, such that they'll be shared by all users and read/writable? The software will operate in a corporate environment where desktops are sometimes pretty locked-down, so for instance some users won't have write rights to C:\Program Files.
I don't think C:\Documents And Settings\All Users\Application Data\ is a good candidate - I think by default only Admins & Power Users have write access here.
I could use each user's Application Data folder, but this would be a bit of a pain as different people could use each machine ... so it'd be simpler if there was just one shared location.
I'm developing in C# .net 2005, but that's probably not too relevant.
Unfortunately you have no real choice. You must (you really must) call SHGetSpecialFolderLocation to get the path to c:\users\public\AppData (which is the name of the folder you linked above, but on Vista and possibly Windows 7)
Then you MUST create your own app folder therein. And then, you MUST, use the security APIs to modify the ACL of the created folder.
There is NO folder on the system with a default ACL that allows multiple non administrator users to read AND write the same files.
c:\users\public\AppData is the closest. Modifying the ACL of a application folder here seems the best approach. Of course, once one has resorted to ACL modification, the folder really could be created anywhere at all. But that could surprise system administrators and result in weired security holes.