Where can I create/modify/delete registry keys to share data between users in the Windows 7 registry? Both of the users are non administrators and it shouldn't require admin privileges.
The application I'm working on uses the registry to write a key from userA and then userB can read/modify/delete it. Neither user has admin privileges and it won't be possible to change this.
Is there an official MSDN guide to how to use the registry in Windows 7? Any links describing proper use of the registry would be useful.
You cannot access HKLM without elevation, so you simply cannot do what you described.
I suggest some of the following:
1. Choose other data storage, eg. database, file, etc. that all your users can access.
2. Create a windows service running as LocalSystem (that gives RW access to HKLM) and make your apps talk to the service via named pipes/COM/a socket.
The registry is for writing configuration settings, not for sharing data between users, you're really using it for the wrong purpose.
However, if you have to, the only place in the registry that would make sense even a little would be in the HKEY_LOCAL_MACHINE hive, in Software\yourapp, but I'm fairly sure that there is nowhere in there that's writeable by normal users by default.
If you are able to, you could create that key and then change the permissions for the users group so that they have full access.
This wiki article might help in seeing how the registry is best used.
On Windows 7, access to HKLM is only for apps running as admin. If you have no manifest on the app, it will virtualize, meaning write to a different per-user storage.
I think you should use a config file in a per-application location that is not per-user, like %PROGRAMDATA%, and have your setup/install (which probably does run as admin) write a single key that tells where this file is. The non admin users can then easily read and write the file while using the application.
The registry is not really the right way to do this. Can you give us some more details about what you're actually trying to do?
Are the users logged in at the same time? In this case, some kind of interprocess-communication (IPC) mechanism might work. For example: named pipes, shared memory, sockets, etc.
If not, will you have a process running at all times (i.e. a service)? This could be used as a sort of drop-box mechanism.
If you've got an installer, you could create a directory that's accessible to both users (put them in the same group, for simplicity's sake). Then you could drop message files in there.
In short: the registry is really designed for long-lived configuration settings. Short-lived communications really ought to be done some other way.
Related
Imagine a web application that performs two main functions:
Serves data from a file that requires higher privileges to read from
Serves data from a file that requires lower privileges to read from
My Assumption: To allow both files to be read from, I would need to run node using an account that could read both files.
If node is running under an account that can access both files, then a user who should not be able to read any file that requires higher privileges could potentially read those files due to a security flaw in the web application's code. This would lead to disastrous consequences in my imaginary web application world.
Ideally the node process could run using a minimal set of rights and then temporarily escalate those rights before accessing a system resource.
Questions: Can node temporarily escalate privileges? Or is there a better way?
If not, I'm considering running two different servers (one with higher privileges and one with lower) and then putting them both behind a proxy server that authenticates/authorizes before forwarding the request.
Thanks.
This is a tricky case indeed. In the end file permissions are a sort of meta-data. Instead of directly accessing the files, my recommendation would be to have some layer between the files in the form of a database table, or anything that could map the type of user to the file, and stream the file to the user if it exists.
That would mean that the so called web application couldn't just circumvent the file system permissions as easy. You could even set it up so that said files did not have server readable permissions, and instead were only readable by the in between layer. All it could do is make a call, and see if the user with given permissions could access the files. This lets you also share between multiple web applications should you choose. Also because of the very specific nature of what the in between layer does, you can enforce a very restricted set of calls.
Now, if a lower privileged user somehow gains access to a higher privileged user's account, they'll be able to see the file, and there's no way to really get around that short of locking the user's account. However that's part of the development process.
No, I doubt node.js-out of the box-could guarantee least privilege.
It is conceivable that, should node.js be run as root, it could twiddle its operating system privileges via system calls to permit or limit access to certain resources, but then again running as root would defeat the original goal.
One possible solution might be running three instances of node, a proxy (with no special permissions) to direct calls to one or the other two servers run at different privilege levels. (Heh, as you already mention. I really need to read to the end of posts before leaping into the fray!)
We're using vlad the deployer for deploying rails apps to production and test servers. All our servers are Ubuntu servers.
We have a problem related with linux permissions.
Vlad uses ssh to put files on any server, be it production or test. My company has several people, and each one has a different account on each server.
On the other hand, the way our Apache server is configured, it uses the "owner" of a website directory for reading files on that directory.
As a result, the user that makes the first deployment becomes the "owner" of the site; other users can't make deployments - Apache will not be able to read the modified files, since the owner has changed.
Normally this isn't much of an issue, but now holidays are approaching and we'd like to solve this as cleanly as possible - for example, we'd like to avoid sharing passwords/ssh keys.
Ideally I would need one vlad task that does something to the permissions of the deployed files so they could be completely modified by other users. I don't know enough about unix commands in order to do this.
I would do it with group permissions.
have the web root be /var/www/your-app/current
/var/www/your-app/ should be group writable by the group that all persons doing deploys belong to.
set up the deploy scripts so that they write to a directory called /var/www/your-app/>timestamp< where timestamp is the current timestamp.
/var/www/your-app/current is a symlink, and when you have sucessfully copied all files to the new directory you update the target of the symlink, so that it points to the directory you created.
This way everyone can deploy, and you can see who deployed what version.
This also makes the deploy atomic, so nothing will break if you lose your network connection in the middle of the deploy.
Since you won't delete the old catalogs, you can easy do a rollback to a "last good" state, if you manage to introduce some bug.
Why don't you make all the files publicly readable? In the ~/.bashrc of each user put the line
umask o=r
http://en.wikipedia.org/wiki/Umask
BTW I have never heard of such an Apache option; are you saying when Apache reads a file from /home/USER it runs with the UID of USER, instead of "nobody" or "apache"? That sounds wonky.
I've been fighting with it for a couple months now and I've only found a couple ways to do it:
Use a single shared account for all the users deploying to the server (boo!)
Use different accounts, but make a chown to a common user account (www-data, rails, or similar) before performing account-dependant tasks (such as the svn update). This might work, but I haven't tested it.
Use access control lists. Someone has hinted at me that this might be the right solution. However, I don't have the knowledge or time to make this work properly.
For now, we are just continuing using one single user per project, and chowning everything manually when needed. It's a bit of a pain, but it works.
I posted this question a while ago regarding where to store non-user specific application data on Linux.
As you can see, I intended to use "/Library/Application Support” on Mac and perhaps "/var/lib" or "/usr/share" on Linux.
On an existing application (currently Windows only) we use “\ProgramData” on Vista & Windows 7 and “\Documents and Settings\All Users“ on Windows XP (both obtained using System.getenv("ALLUSERSPROFILE"), which does not work on Mac or Linux).
The problem I am finding with the Mac & Linux locations (unlike the Windows ones) is that they are not accessible by non-root/admin users, which sort of defeats the purpose of using them.
What is the best practice is this case? We could simply store the application data in the user's home directory. I wouldn't actually be dead against this, as it seems reasonable for the application to appear completely 'new' when a new user tries using it. The main problem this gives us is that each user would have to enter the serial number in order to activate the application (the activation info is part of the 'application data' we need to store). This isn't really ideal.
That said, if there is no real alternative then I suppose it will have to do.
What do you mean by non-user specific application data?
Read-only resources needed by application, such as localization strings or button icons:
on Mac they are stored in application bundle itself, in Resources subfolder
on Linux, they can be stored near application binary, in /opt/<app>/etc for instance.
Read/write properties, such as serial number:
you can consider this information as user-specific application data, so it should go somewhere in $HOME directory
you can consider this information as computer-wide application data, in which case its setting should be perfomed during software installation process, i.e., with administrative privileges.
/Users/Shared/ is writable for everyone. That said, if you need to support computer-wide licenses, the best place for serial numbers, IMHO, is indeed /Library/Application Support. You would have to use Authorization Services once to ask for an admin password and save the serial number there. If a user fails to enter the admin password, save the serial number in ~/Library/Application Support instead.
I have users with limited access granted to one of my hard drives. Those users are not given the permittion to delete the files in that drive. but I have a application that should allow those users to delete files in the above mentioned drive.
1) How can I do this?
2) When a low priviliaged user loged to my application, can I write a hidden thread/ program that that gives high privileged user authority (only for this application), as in impersonating another user, so that he will be abel to delete files via this appliction in the restricted hard disk?
Thanks
Depending on your OS you can do various things.
In a UNIX like environment you can write a program and use setuid or setguid so that it runs with priviledges of another (more priviledged) user.
Alternatively in Windows or UNIX you can run a service as the more priviledged user and let it take requests from other users/processes to carry out the operation on their behalf. You'd have to look into ways to communicate with the service.
Hope that helps.
Probably the easiest way is to write a service which exposes a named pipe, and create a client application which talks to the pipe and issues instructions to your service. The service runs under LocalSystem or a nominated higher-privilege account, and carries out instructions from the app running under a user account with lower privilege. You'd need some sort of handshake to establish bona-fides when you connect to the pipe, but it's not hard to do. You could use WCF instead of pipes, but I don't think you get much advantage from that in this scenario.
In our administration team everyone has root passwords for all client servers.
But what should we do if one of the team members is not longer working with us?
He still has our passwords and we have to change them all, every time someone leave us.
Now we are using ssh keys instead of passwords, but this is not helpful if we have to use something other than ssh.
The systems I run have a sudo-only policy. i.e., the root password is * (disabled), and people have to use sudo to get root access. You can then edit your sudoers file to grant/revoke people's access. It's very granular, and has lots of configurability---but has sensible defaults, so it won't take you long to set up.
I would normally suggest the following:
Use a blank root password.
Disable telnet
Set ssh for no-root-login (or root login by public key only)
Disable su to root by adding this to the top of /etc/suauth: 'root:ALL:DENY'
Enable secure tty for root login on console only (tty1-tty8)
Use sudo for normal root access
Now then, with this setting, all users must use sudo for remote admin,
but when the system is seriously messed up, there is no hunting for
the root password to unlock the console.
EDIT: other system administration tools that provide their own logins will also need adjusting.
While it is a good idea to use a sudo only policy like Chris suggested depending on the the size of your system an ldap approach may also be helpful. We complement that by a file that contains all the root passwords but the root passwords are really long and unmemorable. While that may be considered a security flaw it allows us to still log in if the ldap server is down.
Aside from the sudo policy, which is probably better, there is no reason why each admin couldn't have their own account with UID 0, but named differently, with a different password and even different home directory. Just remove their account when they're gone.
We just made it really easy to change the root passwords on every machine we admininster so when people left we just ran the script. I know not very savvy but it worked. Before my time, everyone in the company had access to root on all server. luckily we moved away from that.
Generally speaking, if someone leaves our team, we don't bother changing root passwords. Either they left the company (and have no way to access the machines anymore as their VPN has been revoked, as has their badge access to the building, and their wireless access to the network), or they're in another department inside the company and have the professionalism to not screw with our environment.
Is it a security hole? Maybe. But, really, if they wanted to screw with our environment, they would have done so prior to moving on.
So far, anyone leaving the team who wants to gain access to our machines again has always asked permission, even though they could get on without the permission. I don't see any reason to impede our ability to get work done, i.e., no reason to believe anyone else moving onwards and upwards would do differently.
Reasonably strong root password. Different on each box. No remote root logins, and no passwords for logins, only keys.
If you have ssh access via your certificates, can't you log in via ssh and change the root password via passwd or sudo passwd when you need to do something else that requires the password?
We use the sudo only policy where I work, but root passwords are still kept. The root passwords are only available to a select few employees. We have a program called Password Manager Pro that stores all of our passwords, and can provide password audits as well. This allows us to go back and see what passwords have been accessed by which users. Thus, we're able to only change the passwords that actually need to be changed.
SSH keys have no real alternative.
For management of many authorized_keys files on many servers you have to implement your own solution, if you do not want the same file on every server. Either via an own tool, or with some configuration management solution like puppet, ansible or something like that.
Else a for loop in bash or some clush action will suffice.
Anything besides SSH logins:
For services you run that are login-based, use some sort of authentication with a central backend. Keep in mind that noone will do any work if this backend is unavailable!
Run the service clustered.
Don't do hacks with a super-duper-service backdoor account, to always have access in case something breaks (like admin access is broken due to a misconfiguration). No matter how much you monitor access or configuration changes affecting this account, this is 'just bad'(TM).
Instead of getting this backdoor right, you might as well just cluster the application, or at the very least have a spare system periodically mirroring the setup at hand if the main box dies, which then can be activated easily through routing changes in the network. If this sounds too complicated, your business is either too small and you can live with half a day to two days downtime. Or you really hate clusters due to lacking knowledge and are just saving on the wrong things.
In general: If you do use software unusable with some sort of Active Directory or LDAP integration you have to jump the shark and change passwords for these manually.
Also a dedicated password management database that can only be accessed by a very selected few directly, and is read-only to all the others, is very nice. Don't bother with excel files, these lack proper rights management. Working with version control on .csv files doesn't really cut it either after a certain treshold.