On Mon, 02 Dec 2019 at 00:28:54 +0100, Simon Richter wrote: > Wasn't there a plan to add support for containers managed through > systemd that have filtered access to the system dbus, or is that just a > special case of a service unit?
As a general rule, "heavyweight" containers with their own init system
that behave like a lighter-weight alternative to VMs (notably lxd and
some uses of systemd-nspawn) have their own set of D-Bus buses managed
by their own init system and process tree, the same as if they were a VM;
while "lightweight" containers that behave more like a chroot (like Docker
and some uses of systemd-nspawn) or a restricted view of the host system
(like most bubblewrap-based containers) either share the host system's
buses, or don't have any D-Bus access at all.
Containers managed as system services by systemd-as-pid-1 are outside
any login session or user-session, so it would not be appropriate for
them to access anyone's session bus. They could access the D-Bus system
bus if desired (with or without filtering). If they access the system
bus, I would expect it to be conceptually the same system bus used by
non-contained system services like NetworkManager, but maybe with fewer
things that they are allowed to do.
Flatpak apps in containers have filtered access to the D-Bus session
and/or system bus from the host system. This is conceptually the same
as if they weren't in a container, but with a firewall-style filter
(xdg-dbus-proxy) between the client and the bus. Not everything is
allowed, but everything that *is* allowed behaves the same as if there
was no container: the same number of buses exist, and their scopes are
the same.
As far as I'm aware, Snap apps are approximately the same shape as Flatpak
in this respect: filtered access to the D-Bus session and/or system
bus from the host system (if you're running Ubuntu's kernel patchset
with AppArmor enhancements), or unfiltered access (otherwise). Again,
this doesn't change the number of buses that exist or what they mean.
smcv
signature.asc
Description: PGP signature
