On Sun, 22 Dec 2024 at 14:39:35 +0300, Michael Tokarev wrote:
> And there's no way to fix [an in-process plugin architecture] in current
> infrastructure, besides switching to dovecot auth (which works by implementing
> a higher-level protocol than saslauthd does).
This is a recurring pattern: if we want a component to be able to run in
a container (and chroots can be viewed as a simple case of containers),
in-process plugins and C-library-ABI-based protocols are often
troublesome, and it's often necessary to have a design where some amount
of "the real work" is done in a separate process, with which the
containerized component communicates via a somewhat stable IPC protocol.
We see this with audio in Flatpak apps working best with Pulseaudio or
Pipewire (a stable IPC protocol to a daemon that does the real work),
erratically with ALSA dmix (an undocumented IPC protocol), and not at all
with JACK (a stable C library ABI that wraps an unstable IPC protocol).
We also see this with Wayland and X11 working quite well across container
boundaries in practice, and protocols over a generic AF_UNIX transport
like D-Bus or Varlink often being container-friendly (if they have been
designed that way - there are plenty of ways to get this wrong).
smcv
