Windows 8: Application is not able write to C:\ProgramData\

Question

I'm porting my application on Windows 8. Program uses path

C:\ProgramData\MyProgramName\

for storing backups. It works good on Windows 7, but it got "Access Denied" when I run it on Windows 8.

What is the proper way and place to store my program's backups (not related to any particular user) ?

This may help: http://stackoverflow.com/questions/16276139/difference-between-program-data-and-appdata . Essentially (I cant find the link I read just a day or two ago, sorry - browser history no findy) You get write access to one folder when installing the program. Later attempts to write to this folder will fail. When trying to write data during actual use of the program (as distinct from the installation phase), you must use a different folder. I suspect that the better place to use is mentioned in the question I've linked to. — enhzflep, Sep 30 '13 at 15:08
@enhzflep The question explicitly asks for an application wide storage location independent of a user account. — IInspectable, Sep 30 '13 at 15:18
@IInspectable - Thank-you, I did indeed miss that requirement. — enhzflep, Sep 30 '13 at 15:25
@enhzflep On a multi-user OS like Windows you cannot consider machine wide storage separately from security. — David Heffernan, Sep 30 '13 at 18:42
@DavidHeffernan - No, of course not. Much as one cant consider the entire memory space accessible from a single user-land process. No Ring0 access, no soup for you! — enhzflep, Sep 30 '13 at 18:54

Stuart · Answer 1 · 2013-10-01T00:13:50.933

5

I see many programs storing their non-user related application data in the common application folder. Ok, actually what they do is create a folder inside the common application folder to store their data.

To get the path to the common application folder, you can call the SHGetFolderPath function with CSIDL_COMMON_APPDATA as the folder id. If don't have to support anything earlier than Windows Vista then you can call the SHGetKnownFolderPath function instead, and pass FOLDERID_ProgramData as the known folder id.

Ah! I did not know that the common application folder is not-writeable by normal users. Luckily there appears to be a recommended solution. See this article on MSDN, Data and Settings Management which states the following "If an application requires normal Users to have write access to an application specific subdirectory of CSIDL_COMMON_APPDATA, then the application must explicitly modify the security on that sub-directory during application setup. The modified security must be documented in the Vendor Questionnaire."

edited Oct 01 '13 at 00:13

answered Sep 30 '13 at 19:03

Stuart

1,428
11
20

`CSIDL_COMMON_APPDATA` and `FOLDERID_ProgramData` typically expand to `C:\ProgramData`. So, how do you deal with the security issue? – David Heffernan Sep 30 '13 at 20:24
@DavidHeffernan: "security" is not a noun you can use in isolation. Secure what information against what adversary? – MSalters Sep 30 '13 at 20:41
@MSalters `FOLDERID_ProgramData` is secured to prevent standard user writing. That's what the question is about. This answer doesn't address that. – David Heffernan Sep 30 '13 at 20:45
@DavidHeffernan: True, but it doesn't make any other assumptions either. Your answer assumes a security model wherein a single hared writeable folder is appropriate. That may not be the case, e.g. another model has per-user subfolders underneath `ProgramData\ApplicationName\` – MSalters Sep 30 '13 at 20:59
@MSalters My answer makes no such assumption. It states that something must be done to deal with the rights issue and presents two common choices. This answer ignores rights which is the crux of the Q. Per user under ProgramData would be very odd. That's like re-inventing the user profile, but behind the system's back. – David Heffernan Sep 30 '13 at 21:08
@DavidHeffernan: The crucial difference is that user profiles are private, whereas the per-user folders under ProgramData would be shared-read, exclusive-write. That's ok if the security concern is integrity, not access. – MSalters Sep 30 '13 at 21:16
@DavidHefferman: I updated my answer to deal with the issue of standard users being able to write to the data folder. – Stuart Oct 01 '13 at 20:25
Thanks for link to official statement by Microsoft. – brgerner Jun 12 '18 at 13:31

score 4 · Answer 2 · answered Sep 30 '13 at 14:41

C:\ProgramData has security settings that prevent standard user from writing there. This is not new in Windows 8, Windows 7 was the same, and the equivalent folder on Vista is also secured in this way. Perhaps your Windows 7 environment has UAC disabled, or perhaps you have secured C:\ProgramData or C:\ProgramData\MyProgramName to permit write access to standard user.

There are a couple of approaches to the use of this folder. Some applications write there only during installation whilst the installer process is running elevated. Then the application itself, which runs as standard user, can read, but never attempts to write.

Another approach is for the installer to create a sub folder of C:\ProgramData that is secured to allow write access for standard user, or whatever user/group that you the developer deem appropriate.

Windows 8: Application is not able write to C:\ProgramData\

2 Answers2