I need to store some data so it can be accessed by the application from any user account.
The amount of data is not big, just several strings.
The storage does not have to be secure, although it would be beneficial. A least the users without admin permission should not be able to spoil it.
I would not mind if the application would require to provide admin password to store the data or remove it. However, when application is launched from another user account without admin rights, it should be able to read this data not asking for any passwords.
Should I use keychain or /Library/Application Support/ folder or maybe something else?
You can share file between different users by using ACL.
Working with Access Control Lists
Share any files between users on the same Mac
Make a folder read-write for all users without using ACLs
I hope this will help.
Related
I would like to know all the permissions a domain user have in my network. Is there any php script,that can extract this kind of information by checking the server and computers in my network?
No, there is no script to do this, and for good reason.
This is a big job that will likely never be 100%. There is no one place that all these permissions are stored, so you would have to decide what kind of permissions you are looking for and find those.
For example, a user could be:
In permissions directly on AD objects (you would have to scan the permissions of every AD object in your domain)
In permissions for files on servers (you would have to scan the entire file system of every server in your environment)
In local groups on a computer, like Administrators (you would have to scan every local group on every computer in your domain, then scan the file system to see what permissions those groups have)
And when you do those scans, you have to look for any groups that the user is a member of too.
You have to decide how deep you want to go: a user could be given permissions on registry keys - do you want to find those too?
There also could be applications that could give permissions to AD groups or to users directly. The list goes on and on.
Essentially I need somewhere to store an expiration date for my software and do not want this to be accidentally deleted (the likelihood of anyone tampering with my software is relatively minimal). I thought about writing this to the registry, however this appears to require administrative permissions. Is there any way to get around this issue?
Thanks
The better alternative would be to use Isolated Storage.
If you really need to modify the registry, and you don't have sufficient privileges to do so, you would need to either ask for an administrator's credentials, so you could temporary elevate your privileges, or you would need to make a request to another process, such as a service, which is already running under another account with sufficient privileges.
If Isolated Storage is a bigger tool than you need for the job, another simpler option would be to use an App.config setting. You can create a setting in your project properties designer screen, and then you can read/write the setting via My.Settings.
I am writing a program in vb.net that requires a user to log in before he can use the application. The main user is created when the program is installed, similar to how windows works when it is installed.
The main user can add additional users to the program. I already know that I should store the passwords encrypted. My question is, where should I store the usernames and passwords? The registry, Isolated storage or .config file. I don't want any user to be able to modify/delete that file as the other user would obviously not be able to log in. Also, this file should be accessible for any user that logs into the computer.
The computer is not guaranteed to be connected to the internet, so it must be stored locally.
Thanks
To tell you the truth if someone has the will power to look for the file they will find it, so storage can help up security but I would focus on the contents of the file itself.
You could try to store the data of the application as a encrypted file which could stop the amateur attempts but as you are using the .net framework your program could could be decompiled and any symmetric encryption algorithms could be rendered useless.
I think your best bet would be to either generate a seed according to the computer the program is on, and if decryption fails call home or go into Lock Down.
Another option would be to store the encrypted (encrypted with your symmetric key) file and a hash file (in different locations probably). If the hash of the loaded file then does not match the hash file your program could then call home (If you have a home to call).
This is just a idea, haven't actually tried anything like this.
If you are not able to use windows users/credentials in any way on the machine, then there really is no absolute way to prevent the file from being removed/changed, Since anyone on the computer has the same access as the main user, who needs rights to modify the file in order for him to add users through the program.
The only way to do it for sure is to have the main user logon with a different user name, and set the file permissions on that file/folder to make sure that only the main user has modify permission to the file (and the other user account does not have the right to modify permissions). I know you said it wouldn't work in your environment(which is?) but you might be able to create users and run stuff under different credentials through your code without having the users log on any different.
The only crazy way I can think of is to create a service on the computer that once it starts running, it opens and holds a handle to that file with sharing set such that no other process can open the file for writing. You'd of course have to workout some way for the main user to be able to add users.
I'm writing a backup program for personal (for the moment at least) use.
For some directories (network directories / protected directories) credentials are needed to access them.
I can setup different jobs in the program to run at specific times.
These jobs are stored in an XML file.
I want to also store the usernames and passwords which the jobs will need.
What and where would be the best way to store these?
Changing permissions on the directories is not an option.
Thanks in advance!
You should never store the logon password for a user in Windows in order to be able to access a local directory. Instead, your backup program should run as a user that has the SeBackupPrivilege enabled (i.e. run the backup from a service that runs as the local system). This means that you won't need to change the permissions.
You may also need to make sure that you are doing a Volume Shadow Copy first that you are copying from - don't copy directly from the disk since that may cause your backup to be inconsistent.
Also, you need to take special care for encrypted files and will need to use ReadEncryptedFileRaw for this.
You could execute the backup program as a scheduled task, running as a specific user.
As for storing passwords you can store them using IsolatedStorage and using a two way encryption to make it harder for someone to decipher the file if they manage to find it.
Check out this SO question for implementing two-way encryption.
I've been working on making my app easier to use for administrators. One of the things I'd really like to do is allow admins to modify other user's settings from within the program -- while still making it possible for regular ol' users to modify their own settings, as my application isn't necessarily only for administrators who want to force users to use specific settings.
I thought of two possible ways of doing this:
1) Move the user setting file path from where it is now (CLSID_APPDATA, commonly Documents and Settings\Username) to a world-accessible path (CLSID_COMMON_APPDATA , commonly Documents and Settings\All Users). Then, save each user's settings to a unique file for the user (probably having a name which equals that of the user's textual SID), so the folder looks something like:
C:\Documents and Settings\All Users\My Company\My Program\settings\123-abc-456-def.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\234-bcd-477-xyz.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\946-hdc-743-ddd.settings
Pros:This allows an admin to see and directly modify any user's settings, because the COMMON_APPDATA path is the same for all users. This is how I'd really like it to be -- it's the most straightforward -- but there's a major con:
Cons:Permissions could be a problem. To allow regular users to save their settings, you'd have to allow users write access to the program's COMMON_APPDATA setting folder.
Of course, when the settings are saved and the setting file created on disk, you'd want to limit write access on the user's setting file to the user who the settings are for, and for admins, so that other limited user's can't modify them.
However, it could be that before a user has a chance to write their own settings from within the program, a savvy, malicious limited user creates a setting file for that specific user, without the knowledge of the user. If the limited user creates the file, that means they own the file... and then that user (who the settings are for) can't modify the settings anymore, unless an admin changes the permissions on the file.
An unlikely situation perhaps, but it still worries me.
2) Instead of moving the setting file path to a globally-accessible path and modifying the user's setting file directly, have my app create and save an "override" file in the app's CLSID_COMMON_APPDATA folder, to allow the admin to override the user's settings.
When my app loads for that user (who's settings were "overridden") it'll detect this file and load it instead of the regular setting file, which is located in CLSID_APPDATA (Documents and Settings\Username).
Pros:Permissions are easy to deal with.
By default, for the Documents and Settings\Username APPDATA folder, only admins and Username can access the files from within. So that in itself protects the user's own regular personal settings from other limited users.
To protect the "override" settings, my app can simply deny write access to the COMMON_APPDATA folder -- where the override file is written -- to all but administrators, and then that's that. These overriding settings will only be modifiable by admins.
Cons:This method is obviously more roundabout. If a user modifies his own regular personal settings, an admin won't see those changes -- the admin can only see the settings he's overriding the user's regular settings with (which he can force the user to use instead).
In some ways, this might be good, but... the fact that it's roundabout turns me off somewhat.
I'm interested to hear what you guys think about this. Which is my best option? I'm personally leaning more towards #2, because while it's less straightforward, it seems to be more secure and isn't so roundabout where it'd be confusing for an admin.
However, I'm also open to suggestions. Is there a superior option you think would work better?
EDIT 7/6/09: I should note that for option #2, the admin could not only override all user's settings with a single override file, but also override an individual user's settings with an override file specific to that user (just like with option #1, that file name would likely be that of the SID of the user who's settings are being overridden). Not sure if that was completely clear in the original post.
Unless there is more than one user account on each computer (i.e. a computer is used by more than one person), option two is the better choice.
Even if there is more than one user account on each computer, I think option two is still a better choice. Worst case, the administrator will have to change settings on a handful of accounts on the same computer instead of one.
If your facility allows random usage of any computer by any person, then option one is the better choice, since option two will make it too difficult to maintain that many different accounts on every computer.
Of course, you can always put the application settings in user folders on the server. That would make it very convenient for an administrator.
If the administrator already has rights to the user's directory where his setting's file is stored, wouldn't that already solve your problem? Either way though, it sounds like option 2 would be best, then you could have a single file that could override say a group of users, then each user have their own settings as well. Just so long as your application is smart enough to tell when to override a setting and when not too, option 2 shouldn't be that much of an issue.