I run Syncthing to keep my KeepassXC in sync across devices. At the same time I have `syncthing-merge`[1] running to handle any conflicts due to concurrent database edits. It calls `keepassxc-cli merge` to merge conflicting databases, which requires my database password. `syncthing-merge` runs as a system service under its own user, so I wasn't able to use a graphical dialog program like GNOME's `zenity` to ask for the password. My solution is to run a user service that can create graphical dialogs in response to requests from system daemons, while enforcing minimal access to the data that the user enters.
With the required NixOS config[2] in place, a system service calls `asker KEY` to issue a request. If that service is a member of the `asker-keys-{KEY}` group, then the request proceeds, is handled by a user service (`asker-prompt`), and then printed to stdout (i.e. to be piped into another program). I took care to ensure that only authorised services could read the user's input.
I looked into using existing keyring programs via the D-Bus Secret Service API, but I couldn't figure out how to control access to individual secrets. I know exactly which services should be allowed to access particular secrets, and I want to enforce that. In particular, I don't want my logged-in user to have universal access to these secrets, because then any program I run can read them (see also: recent discussion of this issue[3]). I also found that these keyring programs aren't suited for ephemeral data; they store secrets for a while.
It might be possible to achieve this using pure D-Bus with access control policies. I haven't looked into this because after I decided that the Secret Service API was insufficient, I figured that rolling my own protocol would be easier than learning D-Bus.
Questions for you:
* Which wheels could I have avoided reinventing?
* Is there anything I could simplify?
* Have I failed at my security goals due to mistakes or oversights?
[1]: https://github.com/LightAndLight/syncthing-merge [2]: https://github.com/LightAndLight/asker?tab=readme-ov-file#us... [3]: https://news.ycombinator.com/item?id=46278857