Windows 7: File permissions in Windows 7

Hello all,
I have a custom application that was written in Labview. As part of the application, the user wanted some of the program configurations saved. In Windows XP, I would typically store the configuration (or ini) file in the same subdirectory as the executable. This cannot be done in Windows 7 due to file permissions in the Program Files subdirectory. I determined that there is a hidden subdirectory call ProgramData that is supposed to be used for this purpose. Everything works fine if only one account uses the software. The configuration file can be written and read properly. Unfortunately many users will be using the software and they all would like to log into the computer under their own account. If a different user logs in, the software can read the file but cannot modify the file with any changes that the new user made. All users have administrative privileges and the permissions on the files seem to allow RW privileges. The only exception that I have found is that the owner of the file somehow plays a part in this but I cannot seem to figure out a way around it (other than everyone logging in as the same user).

Any ideas? Is there another place on the hard drive that is supposed to be used for this purpose that allows full RW privileges?

Thanks!

Welcome to the forum! The file is shared, with everyone allowed acces and read/write selected?

You want same settings for ALL users??
Who has RW permissions... everyone, users or administrators?

Default the permissions in that folder are:
system, administrators, owner : full control
users: read+exceute

As far as I know, there is no folder in the default Windows 7 installation that have such access privilege. Program data, as well as public users have read-only permissions to standard users and full control for the creator of new files (and other users get only read permissions on those), hence the problem you describe.

The best location I can think of is the public folder from which you can create a new folder for all those shared files and give that the proper permission. I think that c:\users\public\<your program>\<whatever you need> is a good option.
But in any case you need to set permissions manually. A good way may be, in the installer of the program, to setup this folder and give the built-in "users" group read-write permissions on everything on that new folder, so that files created by one user may be written by others too.

DMHolt57,
Thanks for the welcome. The file is created by the program so I assume that it inherits the permissions of the current user. All users should be administrators on the computer.

Kaktussoft,
Yes, I would like the permissions to be the same. Think of the file as the old .ini files that many programs used. INI files typically stored user preferences and other things like form location, etc.

Alejandro85,
I hope that this is not the only option to make this work. Since Win 7 has put so many restrictions on the file permissions, is the only other option the registry?!? I certainly would like to avoid having to get into the registry mess for something so simple. All of the commercial software packages that I have must have a way to store the preferences for their programs.

What you are seeing is a well-known issue, and it's probably worth reiterating that common user locations (in this case, %allusersprofile% which points to ProgramData) in either the registry or the file system is really the place to store global information about the program that is needed to be generated when program installation occurs (only), as any location outside of the user's profile or registry are not supposed to be used as program configuration databases. Continued writing to files or the registry in non-userprofile locations to update settings is, in general, bad development practice, for at least one major reason.

Obviously, this folder is there for appcompat reasons, as some programs still try to use %allusersprofile%, which doesn't actually exist anymore on Vista and higher systems. It simply junctions to \ProgramData, which as already mentioned only allows SYSTEM, Administrators, and CREATOR OWNER full control to data created here. Users have Read/Execute, and no write rights.

The real issue is, the "best practice" (and what Microsoft is trying to force you to do) is to avoid changing settings globally for all users on a continual basis. This is something that you'd expect (and as "best practice") you should consider modifying on a per user basis instead (app should write to %localappdata% or %appdata%, not %allusersprofile%). Expecting users that run your app to always be administrators in a Vista + environment is a bad idea too, because you aren't likely to have that be the case (if the org cares anything about security, they are certainly not allowing that). If there's a REAL need, you could always consider creating an alternate location on the system, modifying permissions on that location to be Medium IL and allow users RWX perms on that locatiion (either programmatically or icacls), but again, this is really not a good idea and should be considered an appcompat stopgap measure until a LUA compliant application can be written to work properly without these workarounds.

Ultimately, development best practice is to assume the user has Medium IL and General User rights, meaning the right place to be writing application data after installation is to appdata in the user's profile (again, %localappdata% or %appdata%), not anywhere else as General Users are not going to have write access to those locations if they're not admins - and even if he user WAS an admin, assuming the org still cares about security, UAC would still be enabled, and there'd be a UAC prompt every time that occurred in standard scenarios. This really is considered less than optimal (and insecure) development practice and makes fairly poor assumptions about user rights on a secure system.

Long story but true for sure. I would advise OP to put default settings in %alluserprofile%\ProgramName (created on application install). And let users have a copy of it in %appdata%\local\ProgramName.

If program starts and user private config doesn't exist .... copy it from alluserprofile. If some (new) setting is not in private config .... copy setting from alluserprofile. If a user changes the settings he changes his own private copy.

This is the best I know to make such a thing work, if you really want read/write access for some files for all users. Windows 7 in fact hasn't changed the default file permissions at all and XP would pose the very same problems too.
Nobody here has ever mentioned the registry. The file system permission has nothing to do with the registry, and you can't control them from it. But, by the way, if you even try to store such files as registry settings, you would have the very same issue, as HKCU has full control for the current user only, and HKLM has read only for everyone, but nothing has read/write for all. Just set the permissions to a folder in a well defined location to be read/write for all users at installation time and use that.

All other programs you use often use per-user settings. Most of the use the c:\users\<user>\appdata folder for its settings or HKCU on the registry both of which have full control for the "current" user and no access for all others, but that's not what you need, since you need something a little different, a place where everyone can modify everyone's file. For most programs, settings in one user don't affect at all the settings for others.