Service configuration for keyd is missing CAP_SETGID

mprasil commented 6 months ago

Describe the bug

When service is starting it will print out the following line:

WARNING: failed to set effective group to "keyd" (make sure the group exists)

This suggests that the service wants to setgid into the keyd group. However if user tries and adds users.groups.keyd = {}; into their config, keyd no longer starts properly:

keyd[74488]: setgid: Operation not permitted
systemd[1]: keyd.service: Main process exited, code=exited, status=255/EXCEPTION

The reason is that the configuration is missing CAP_SETGID.

This can be resolved by setting following:

systemd.services.keyd.serviceConfig.CapabilityBoundingSet = [
  "CAP_SETGID"                                               
];

But perhaps that capability should be there by default or conditionally if keyd group exists?

Steps To Reproduce

Steps to reproduce the behavior:

Enable keyd service: services.keyd.enable = true;
Declare keyd group: users.groups.keyd = {};
Observe keyd crashing on startup: journalctl -u keyd

Expected behavior

The service starts.

Additional context

Add any other context about the problem here.

Notify maintainers

@peterhoeg

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.76, NixOS, 23.11 (Tapir), 23.11.20240213.01885a0`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add a :+1: reaction to issues you find important.

paperdave commented 2 months ago

ran into this while setting up nixos and so on, surprised that the keyd group doesnt exist from keyd.enable=true. is that part intentional? i feel like all of it should be setup just from the one flag, since i dont think keyd is as useful without keyd-application-mapper

peterhoeg commented 2 months ago

Couple of things here.

First of all, I'm not using keyd (kanata ftw!) so if any of you (or somebody else) have an interest, the maintainership is available.

Secondly, is there any issues with the group not existing (other than the warning)?

Lastly, the proper way to run this is using DynamicUser = true; which people have tried but not had much success with. There shouldn't really be any reason why it wouldn't work though.

paperdave commented 2 months ago

Secondly, is there any issues with the group not existing

there is a secondary application, keyd-application-mapper, which is optional but quite handy. it lets you reconfigure mappings per-application. the way i understand this is the group is simply for what users are allowed to send re-configuration events to the daemon. so if the group does not exist, it is impossible to

im not sure if the warning affects anything. i did not test much

kanata ftw

very cool. i would check this out if i hadn't just set up keyd, haha. looks nicer since mac+windows support.

for what it is worth, i have a local patch to the nixos module which works for me. i could upstream the changes to a PR if that's desired (could also look at the DynamicUser issues), but i don't want to take the role of a maintainer right now.

voronind-com commented 2 months ago

keyd-application-mapper is extremely handy thing to have. I hope we won't look at it as "optional" :0) I was able to recreate all the same shortcuts for Firefox, Jetbrains, games etc without configuring the applications.

I don't mind spending time on this, but I have no prior experience with maintaining nixpkgs packages. So you might consider me as a candidate with a low priority in case no one else would like to take it.

gilest commented 2 weeks ago

Ran into the same issue today and can confirm that the suggested resolution fixes this issue

NixOS / nixpkgs