2

So all x86 code normally resides under %ProgramFiles(x86)% folder, while x64 code resides under the %ProgramFiles% folder.

Many applications, especially when installed in two variants, one for each architecture and in their respective folders, would share and depend on a number of assets that aren't code and to which the concept of CPU architecture doesn't apply. That would be assets of all kinds -- documentation, help and localization files, multimedia, perhaps etc.

Is there a preferred location reserved for such files, so that an application that is installed in two variants like above, doesn't have to maintain two identical sets of assets for no good reason at all?

%ProgramData% seems to be an ill-fit because, for one thing, it's designed to be writable by regular users, something that isn't safe with regard to often critical application assets interesting candidate since its ACEs effectively allow only creator of a folder therein to modify it and any files they may create in the latter.

For comparison, on Linux-based systems, there has been just the thing for such assets, quoting section 4.11 of the "Filesystem Hierarchy Standard":

The /usr/share hierarchy is for all read-only architecture independent data files.
...
Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share.

I'd like to know if there is one like that on Windows? As an application developer (and application end-user) I am reserved about storing assets somewhere like C:\<folder-name> or another equally poor location.

Eryk Sun
  • 33,190
  • 5
  • 92
  • 111
Armen Michaeli
  • 8,625
  • 8
  • 58
  • 95
  • `%ProgramData% ... designed to be writable by regular users` Not exactly. Default write/delete permissions are restricted to creator/owner, so if your installer runs elevated (which it needs to, for access to %ProgramFiles%) and puts data under %ProgramData% regular users will not be able to change/delete it without elevation. See for example [this](https://stackoverflow.com/a/40575133) and the other linked answer. – dxiv May 11 '20 at 19:00
  • This may vary, I suppose, but my Windows 10 has "Users" with "Write" permissions for "this folder and subfolders" on `%ProgramData%`. So in order to guarantee regular users can't mess up assets I put in a folder in %ProgramData%, I'd have to add an uninherited ACE that denies them the privilege. In any case, I am not sure `%ProgramData%` is for read-only application assets. – Armen Michaeli May 11 '20 at 20:52
  • Checked another Windows 10 host I have access to -- same story with permissions. – Armen Michaeli May 11 '20 at 20:54
  • Have you actually tried it? Create a directory with a file in it from an elevated cmd prompt, then try to edit or delete it without elevation - you'll get an access denied. Windows achieves this with a play on rights *and* inheritance in the %ProgramData% root, if you look carefully. – dxiv May 11 '20 at 20:56
  • 1
    Per the default rules inherited from ProgramData, the SYSTEM account, administrators, and the creator have full control, and standard users only have read and execute access to existing files, but standard users also can create new files and subdirectories, to which as creator they're granted full control. If you don't want users to be able to create new files and subdirectories in your application's ProgramData directory, then you'll have to set a custom security descriptor on the directory when creating it. – Eryk Sun May 11 '20 at 20:58
  • Like I said, on two hosts (one absolutely vanilla Windows 10 I keep as a revertible-to-OOBE VM), there is an explicit uninherited create-folders;write-data;write-attributes;write-extended-attributes ACE for "Users" group on the `%ProgramData%` folder, meaning that any user can add folders and write files in the folder and its descendants that inherit their permissions from the former. One doesn't have to be creator/owner of a folder or file therein to do so. I tested it before asking the question and can re-confirm this. – Armen Michaeli May 11 '20 at 21:14
  • To make things clearer -- @dxiv you are right, regardless of the ACE -- yes, if an Administrator principal adds a folder or files under `%ProgramData%`, regular users can't modify these. Am I to understand this is a recommendation to use `%ProgramData%` as the kind of folder I am looking for? – Armen Michaeli May 11 '20 at 21:17
  • 1
    You said "in order to guarantee regular users can't mess up assets I put in a folder". They cannot. They can only create *new* files and subdirectories, to which as creator they have full control. They cannot modify (mess up) existing files that they did not create. That said, being able to create new files and directories in your application's ProgramData directyory can mess things up if said files have a reserved, special purpose if they exist. You can either pre-create all reserved files, or set custom security on the directory to prevent users from creating new files and directories. – Eryk Sun May 11 '20 at 21:21
  • @ErykSun Thank you. To address the last sentence in your comment -- I have no problem with people adding folders and files in the folder I create in `%ProgramData%`, I only need to guarantee integrity of shared asset material my application installer would install there. Which, it seems, it will, even without explicit ACEs on the folder (which requires a custom action because there is a bug in Windows Installer, if I recall correctly). Maybe add an answer, so others can benefit from this? – Armen Michaeli May 11 '20 at 21:26
  • 1
    Just make sure the directory isn't lazily created (after installation) as the current user of the session. It should be created by an administrator, SYSTEM, or TrustedInstaller at the time of installation. For example, my system has a "%ProgramData%\Microsoft OneDrive" directory that's owned by my current user and to which I thus have full control. This looks like a mistake to me. – Eryk Sun May 11 '20 at 21:31

0 Answers0