Is it obvious that giving access to Everyone with full permissions on folders in the C:\ProgramData is not safe and can lead to privilege escalation.
My question is how is the situation for text files? Is it still dangerous?
Is it obvious that giving access to Everyone with full permissions on folders in the C:\ProgramData is not safe and can lead to privilege escalation.
My question is how is the situation for text files? Is it still dangerous?
No, it is not "dangerous" to give multiple users write access to a .txt file but you will run into problems if multiple users try to edit the file at the same time.
This basically only applies to text files, anything else like HTML or pictures can be problematic if there is a bug in the application that opens these files and a normal user has edited the file to include some exploit and then waits for an administrator to open it.
The program data folder and other common folders are supposed to be read-only for normal users...
Related
So, I stumbled across a little problem, I can't seem to figure out.
I have a NAS where I dump data on and a script to download files I need back to my PC.
While doing so, it creates a folder for the file. After that, I run a different script that encodes the video files to save some space.
However, for some reason, the files and folders keep getting a 'read-only' lock that prevents the source file to be deleted after compression.
So I have to get into each individual folder and remove the read-only permission.
Is there some way to disable the read-only lock?
The Owner if the Root folder is my personal account, with full access.
Changing it to SYSTEM or Admin with full access doesn't change anything.
Our software automatically creates a directory in the users documents containing sample files, log files etc. However, we want to give the user the opportunity to change this directory (as I personally hate software that "forces" you to use their suggestion). The path to this directory is therefore not hardcoded but is part of a file containing user settings.
The obvious place to put the user settings file is in the above mentioned directory within the users documents. This of course creates a contradiction (the software wouldn't know where to look for the user settings as the path is in the user settings). We usually just put this settings file with the exe, so in most cases that would be in the Program Files. This however creates problems when the user has no admin rights because some of the settings can be changed from within the software and are then written to the file.
What is the most elegant way to solve this?
This is what the AppData folder is for
Microsoft Explanation
As pointed out in Writing config file in C:\Program Files (x86)\MyApp\myapp.cfg, vs. Administrator privilege, it is not a good idea to write a config file in C:\Program Files (x86)\MyApp\myapp.cfg.
Instead of this, my software now saves its data in a subdir of %ALLUSERSPROFILE% (ex : C:\ProgramData\MyApp\myapp.cfg on Win7)
[I use myfile = open(filename, 'a') in Python to do this.]
I now encounter an issue about this file :
I installed the software with User A, and ran it, then the file C:\ProgramData\MyApp\myapp.cfg was written.
Then, I changed user to User B, and ran my software again : now an error is displayed : User 2 has no right to write in C:\ProgramData\MyApp\myapp.cfg (Permission denied).
Why? Isn't %ALLUSERSPROFILE% a place that can be written by all users?
How to solve this problem ?
No, C:\ProgramData, aka FOLDERID_ProgramData, has restricted security settings. Standard users can create files there. But these files are, by default, secured so that only the user that created the file can subsequently modify the file.
The recommended solution is for your installer to create a sub directory of C:\ProgramData for your shared storage. And that sub directory must be given a permissive ACL by the installation program. That is what grants the desired access to all standard users.
I do wonder whether you really need shared writeable data. Normally I'd expect to see shared configuration be something that is specified at install time and modified infrequently by administrators. Most configuration data tends to be per user.
I'd like to add onto this as I was having issues writing to C:\ProgramData as well. My issue ended up being that my directory/files within C:\ProgramData were written by an administrator. When my app ran under a normal user it was unable to write there so Windows automatically used C:\Users\fooface\AppData\Local\VirtualStore\ProgramData instead. I found the path it was writing to by using process monitor on my application. After seeing this I deleted the files out of C:\ProgramData and ran my app again and it wrote there as expected.
Hope this helps someone.
We are migrating our APP to Win7. The program generates log files to help us support and also saves a number of dictionary files and settings files that are useful for the user though the user will rarely if ever actually want to interact with the files outside of our application. They can though because they are csv files. I built the first run through with using the APPDATA\LOCAL\OURAPPLICATION folder as the destination. Now I am wondering if it should be PROGRAMDATA\OURAPPLICATION.
I actually think the first choice is better because it seems that everything I have scanned suggests that the PROGRAMDATA folder should be considered untouchable by the user but as I am not a programmer I am not sure.
I hope this is the right place to ask this question
The key point to consider is what the scope of the data is. If you are storing data that is associated with a specific user then you should use APPDATA and if you are storing data that is global to your program then you should use PROGRAMDATA.
Both APPDATA and PROGRAMDATA are hidden folders so the intent is for users not to be poking around in there (not that they couldn't if they wanted to).
Currently, I'm developing a system which will extract some files from an SFX archive (files that will be used for another app). I want to make the extracted files hidden, so the person which has find the location of the exe couldn't get the files which will be in same directory with the exe. I know i can apply attrib +h to the files but if the user turns on "show hidden and system files" option in Windows, the files will be visible.
Isn't there any method to overcome this? Any suggestion is welcomed.
Thanks.
If you're writing to the disk, a user can find and read your file. There's no way around that, one could monitor what happens when your application is run, find what files it's writing to, or just intercept while it's being written. Consider why you don't want the user to find your files.
Is it because there's sensitive data, or things you'd rather they didn't change? Consider encrypting it, or verifying it's integrity with a checksum or hash.
Guess you could play around with user rights. However, you'd need to ask an administrator right at install then to make it hidden from the given user who is an admin on the PC.