File permissions in Windows 7

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?

awperli said:

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!

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

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.

cluberti said:

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.