nixos/paretosecurity: Add support for declarative linking #432756
Conversation
Before this PR, users that wanted to link their Pareto Desktop to Pareto Cloud had to imperatively run `paretosecurity link ...`. This PR adds a oneshot systemd service that does the linking so the entire Pareto app can be configured declaratively with nix.
9831c44 to
090d064
Compare
| users.users = lib.mkOption { | ||
| type = with lib.types; attrsOf (submodule userOptions); | ||
| }; |
There was a problem hiding this comment.
I don't think it's a good idea to add this to users.users as this option would show up regardless of whether this module is enabled. If every module started adding their options to users.users this would be quite a mess.
I also don't think that what you want is a user abstraction in the Linux sense at all. As far as I understand it (from reading the website), you care (mostly) about device settings (esp. when I look at https://paretosecurity.com/linux/checks) and most of the abstractions seem to be on the device level, assuming there is one user per device.
I'd suggest to just have a single inviteId to link the entire device as opposed to assuming this is a multi-person workstation. If you really want to do this for multiple users on the same device, please implement this via a separate option like paretosecurity.users.${name}.inviteId.
There was a problem hiding this comment.
Thanks for taking the time to review!
-
Some of the settings are per-device, but there are definitely per-user settings that need to be checked for compliance. It's probably fine to focus on single-user scenario for now, but long term I imagine we'll need support for multi-user.
-
My main reason for using
users.users.alice.paretosecurity.inviteIdis to have validation that the user actually exists. I.e. if someone hasusers.users.aliceand thenparetosecurity.users.bob.inviteId, I want nix to complain. Is there a way to useusers.users.alice.paretosecuritywithout polluting theusers.usersmodule if paretosecurity is not enabled?
There was a problem hiding this comment.
I want nix to complain.
You could write an assertion that checks this at build time of the system.
However, you should also consider that some people manage their users outside of Nix. I.e. via mutable users or LDAP, where they won't show up in Nix. Especially for larger organizations LDAP is quite common.
I think that runtime checking (i.e. in the service) would be the most flexibe and future proof, but I don't have strong opinions about this. Just some pointers.
There was a problem hiding this comment.
I think this would really be way better suited as a home-manager module (which can be included into your main NixOS configuration), creating systemd user services for the given user.
We don't really have a concept of per-user settings in nixpkgs / NixOS itself.
But not everyone uses home-manager? |
nixpkgs doesn't have the infrastructure to define something only specific to one user and their config, and so far the solution was to land this code into home-manager. Running something as the user, but via a global systemd system unit won't fully enter a user session, and not work in some cases (xdg config home decrypted on login etc...). I still think this should land in home-manager, and for people not wanting to use it to manage this aspect of paretosecurity, they can run |
Before this PR, users that wanted to link their Pareto Desktop to Pareto Cloud had to imperatively run
paretosecurity link .... This PR adds a oneshot systemd service that does the linking so the entire Pareto app can be configured declaratively with nix.Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.