nixos/espanso: provide required capabilities for espanso-wayland

[n8henrie]

On wayland, espanso relies on capabilities for its worker process to function.

Unfortunately it forks itself using current_exe() to find the binary, which resolves to the capability-lacking binary in the store instead of a wrapped binary provided by security.wrappers.

Extensive discussion of the problem and alternative solutions in #328890.

As compared to that PR, which has not made much progress, this is a dramatically simpler approach that seems to work well.

Happy to incorporate constructive criticism, as I am not terribly familiar with security.wrappers and suspect there may be better ways to e.g. find the wrapped espanso, test for pkgs.espanso-wayland, etc.

Fixes #249364

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[pitkling]

Thanks for taking another try at this, @n8henrie. The changes look good to me, but I currently don't have access to a NixOS Linux system (not for a few weeks), so I won't be able to test this for the moment.

Would be great to finally have an espanso-wayland that works out of the box :).

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/5662

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2503

[Vortriz]

gentle ping, in case this slipped away

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/espanso-daemon-problem/35309/28

[n8henrie]

Haven't had much luck getting reviews in the months since this PR was created.

Pinging maintainers from the home-assistant module. Do any of you have access to a wayland system to test and possibly review? Would love to get espanso working on wayland by default!

@bobvanderlinden
@liyangau
@lucasew
@phanirithvij

[bobvanderlinden]

I gave this a try. I haven't been using espanso actively for a while, but it was already working for me on Hyprland with with the home-manager module. I do indeed see:

Oct 20 23:40:16 nac44250 espanso[29696]: 23:40:16 [worker(29696)] [WARN] EVDEV backend is being used, but without enabling linux capabilities.
Oct 20 23:40:16 nac44250 espanso[29696]: 23:40:16 [worker(29696)] [INFO] monitoring the status of the daemon process
Oct 20 23:40:16 nac44250 espanso[29696]: 23:40:16 [worker(29696)] [WARN]   Although you CAN run espanso EVDEV backend as root, it's not recommended due
Oct 20 23:40:16 nac44250 espanso[29696]: 23:40:16 [worker(29696)] [WARN]   to security reasons. Espanso supports linux capabilities to limit the attack surface
Oct 20 23:40:16 nac44250 espanso[29696]: 23:40:16 [worker(29696)] [WARN]   area by only leveraging on the CAP_DAC_OVERRIDE capability (needed to work with
Oct 20 23:40:16 nac44250 espanso[29696]: 23:40:16 [worker(29696)] [WARN]   /dev/input/* devices to detect and inject text) and disabling it as soon as the
Oct 20 23:40:16 nac44250 espanso[29696]: 23:40:16 [worker(29696)] [WARN]   initial setup is completed.

I can confirm that when I have in configuration.nix:

  services.espanso = {
    enable = true;
    package = pkgs.espanso-wayland;
  };

Now the log shows: using EVDEVInjector without the errors.
So to me this PR seems like an improvement already. It avoids the errors. Merging makes sense.

I am wondering: is this only usable for espanso-wayland? Why not always create the wrapper, regardless of package == espanso-wayland?

[n8henrie]

Thanks for the review!

it was already working for me on Hyprland with with the home-manager module

Interesting -- I'll need to look again, I only use the hm module on Darwin, but I don't see why it would work through HM; I would expect Wayland to fail there as well due to the lack of capabilities etc.

As to only applying the wrapper on Wayland -- that was just because they're only required on Wayland. Figured X11 users might not want the small incremental security cost of an extra capabilities-enabled binary on their system if it didn't give them any extra functionality.

[n8henrie]

@bobvanderlinden it is definitely failing for me with Arch on wayland (sway) with a home-manager-only setup. Still working on getting Hyprland to run -- darn nvidia GPU issues.

[n8henrie]

Integration tests added in #454248 -- once this PR is merged, the wayland test passes.

[niklaskorz]

This should also be moved inside the package definition, behind a flag (I lack the creativity for a proper name, but something like inSecurityWrapper). Also, use postPatch instead of patchPhase for such substitutions.

[niklaskorz]

Even better, the flag could be the path to the exe, e.g.

{ ..., securityWrapperPath ? null }:
stdenv.mkDerivation {
  ...

  postPatch = lib.optionalString securityWrapperPath != "" ''
    substituteInPlace espanso/src/cli/daemon/mod.rs \
      --replace-fail \
        'std::env::current_exe().expect("unable to obtain espanso executable location");' \
        'std::ffi::OsString::from("${securityWrapperPath}");'
  '';

  ...
}

[n8henrie]

@niklaskorz Maybe a little more discussion on this one -- I specifically did not include this in the package because the package itself is also run on non-NixOS linuxes and should not have this applied in that case. In my mind, this workaround should only be applied through the NixOS module (as that is the only case in which the security wrapper script will exist).

Does that make sense? Do you think there's another path?

[n8henrie]

Although I suppose the securityWrapperPath should be assumed to be null in those cases, so it shouldn't affect them...

[niklaskorz]

Yes, my suggestion is mainly meant to make it easier to fix the patch on updates, having it all in one place.

[n8henrie]

Migrating the new nixostests to this PR, since this should establish Wayland as working. Will close #454248 when / if this is merged.

[niklaskorz]

Looks like you accidentally included two unrelated commits with the last rebase.

[n8henrie]

Ugh, sorry and thanks.

[n8henrie]

Working on changing the package definition as suggested. Trying to test locally before I re-push.

[n8henrie]

For some reason the nixosTests aren't working from my aarch64-darwin machine anymore. Will need to do a little more debugging once I get home to a linux machine -- hopefully this evening.

[niklaskorz]

Tests pass, changes look good. Might be preferable to fetchpatch the package fix instead but I'll leave that up to you.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/using-espanso-on-wayland-nixos/55268/6