Re: Policy: should libraries depend on services (daemons) that they can speak to?
On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote:
> "Theodore Ts'o" <tytso@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
Reply to: