-
-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve setting permissions on /run/keys. #206
Conversation
This makes it at least possible to access the keys directory if a particular service is in the keys group, which has been introduced by NixOS/nixpkgs@4ab5646. However, to let specific users access a particular key, you still need to work around it by adding an additional systemd service that sets the right permissions. But at least with this we should have some consistency with what is actually done in <nixpkgs>. Signed-off-by: aszlig <[email protected]>
Allowing more control over the /run/keys using such a attribute set sounds nice indeed. Should be able to make it backwards compatible as well right? |
This now provides options for each key and also converts old style string-only keys into the new format while emitting a warning. At the moment only the "text" option is actually supported. For applying the keys for string-values the permissions attribute is set to "0600" instead of the default value "0640" in keyOptionsType in order to correctly replicate the old behaviour even when we implement permissions and ownership. Signed-off-by: aszlig <[email protected]>
This however only implements setting permissions if "storeKeysOnMachine" is set to false right now, because if the value is set to true the keys are symlinked from the store and we actually have to find a way to control permisions on it, which for the store is only possible if NixOS/nix#8 is implemented. Also, this ensures that the key filename is properly escaped. Signed-off-by: aszlig <[email protected]>
First, forgot about specifying options.* and even if it would be there, the option values wouldn't be merged because keyType was not properly inheriting the merge function from keyOptionsType. Signed-off-by: aszlig <[email protected]>
Only using this for legacy options could introduce unexpected behaviour when switching to the new configuration if the user just appends a .text to its configuration values and could possibly lead to services that refuse to work, especially when it comes to OpenSSH. Signed-off-by: aszlig <[email protected]>
This currently only fixes evaluation but actually doesn't apply the correct permissions on the key files because they're just links to world readable files in the Nix store. Signed-off-by: aszlig <[email protected]>
As storeKeysOnMachine no longer is true by default (7ae4b27), we shouldn't say so in the description. Especially because the default value is already shown in the generated manual along with the description. Signed-off-by: aszlig <[email protected]>
@rbvermaa: Implemented so far, but if So if that's okay and there are no other issues, it's ready for merge :-) |
I would add assert for it. I wouldn't know a use-case for setting permission that can't be set. |
OTOH: Isn't storeKeysOnMachine kinda pointless the way it is right now? Because if someone wants to refer to a key (s)he can simply just add it with |
Hm, another issue is that there is no |
Okay, I was wrong, there is a @rbvermaa: My idea would be to use |
Okay, the user/group part is resolved by #207, because it really doesn't make sense to send keys to the rescue system, where we don't even have |
This warning should be annoying enough so people will eventually set it to false in case they ever used it. Especially if we want to set key permissions, setting this option is pointless anyway because keys in /run/keys are just symlinks to the world-readably store paths. Signed-off-by: aszlig <[email protected]>
So far we only used the apply function in order to convert keys as string values into the new format. But if you have several keys defined, mixing old and new format, the evaluation will fail because the apply function is only evaluated once everything is merged. So, we now use the same function we're using for apply to merge the consecutive option values. Signed-off-by: aszlig <[email protected]>
Improve setting permissions on /run/keys.
We had NixOS/nixpkgs@4ab5646 so far which introduced the
keys
group in order to theoretically make it possible to allow access to other users than root, practically for NixOps we need to make sure we're allowing access to the group as well.So, right now it's only setting the group ownership for
/run/keys
, but I'd go even further into changingdeployment.keys.*
into a nested attribute set, which would look like this:Which then sets the appropriate permissions on the key itself. Unfortunately this will break backwards-compatibility, so I'm waiting for better ideas/suggestions before implementing it that way.
Latest build/evaluation at: https://headcounter.org/hydra/jobset/nixops/keys-permissions/latest-eval