On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote: > "Theodore Ts'o" <ty...@mit.edu> writes: > > I'll argue that best practice is that upstream [should] make the shared > > library useful *without* the daemon
Is the argument here that any design that separates into clients and a non-optional server (for example to do privilege separation, or to mediate indirect access to a non-shareable resource) is fundamentally flawed? If yes, then goodbye to task-desktop, because X11 and Wayland are both among the protocols that work like that. I would personally like to see *more* privilege separation across IPC boundaries rather than less, if that can reduce the total attack surface of the setuid/setcap executables in the trusted computing base. I'm sure you're one of a few developers in Debian who can successfully navigate the hazards involved in writing a safe setuid executable without making security-sensitive mistakes, but that puts you in a small group whose limited time doesn't scale well. On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote: > 2. Weaken the dependency between the shared library and the daemon so that > the shared library can be installed without the daemon even though it's > objectively useless in that situation because it's the easiest and > least annoying way to let the application be installed without the > daemon, and that's the goal. This is what we have typically done for sound servers (PulseAudio, Pipewire, Jack and friends), for X11, for Wayland, and for optional uses of D-Bus, among other frameworks where the separation into server and client is sort of the point. For uses of D-Bus that are important or essential to the application, typically it is the application rather than the client library that has a weak or strong dependency on {default-,}dbus-{system,session}-bus and the appropriate service to talk to. That works fine if the service we're talking to is something that we expect "most" desktop environments to have pulled in somehow, but the cost of that approach is that every component needs a plan for how to cope with the server not being there. For instance, for password storage (gnome-keyring, kwallet and other such things), the fallback will typically be to write the password to a flat file that will not be encrypted-at-rest (unless the sysadmin has taken steps to use system-level encryption), which is a perfectly viable implementation but seems non-ideal as a default. smcv