Re: [Buildroot] [PATCH v6 1/4] package/dbus-broker: new package

[Norbert Lange <nolange79@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 7267 bytes --]

Arnout Vandecappelle <arnout@mind.be> schrieb am Mi., 27. Juli 2022, 19:05:

>
>
> On 27/07/2022 15:47, Norbert Lange wrote:
> > Am Mi., 27. Juli 2022 um 13:08 Uhr schrieb Arnout Vandecappelle
> > <arnout@mind.be>:
> >>
> >>    Norbert, Yann,
> >>
> >>    As usual, apologies for taking so long to review this. It's because
> it's a bit
> >> complicated. I actually tried to look at it just after our hackaton in
> January
> >> but it was too complicated to quickly get my head around.
> >>
> >> On 09/01/2022 23:16, Norbert Lange wrote:
> >>> dbus-broker is an alternate implementation of a dbus dameon. It can be
> >>> used as a drop-in replacement for the system bus daemon, as well as the
> >>> session bus daemon.
> >>>
> >>> dbus-broker is (basically, and as far as we're concerned in Buildroot)
> >>> split in two components:
> >>>
> >>>     - the actual message bus daemon, that relays messages across
> clients
> >>>
> >>>     - a launcher, which is responsible for setting various aspects of
> the
> >>>       bus, like setting the policy et al. and opening the socket(s) the
> >>>       message bus daemon will have to listen on...
> >>>
> >>> The launcher can only be used in a systemd setup (it makes heavy use of
> >>> systemd facilities), while the message bus is generic. However, the
> >>> message bus daemon is useless without a launcher. There does not exist
> a
> >>> non-systemd launcher, which makes dbus-broker actually a systemd-only
> >>> package; this can be revisited when/if a non-systemd launcher appears.
> >>>
> >>> Note, however, that libdbus is not provided by dbus-borker. People who
> >>> want to use dbus-broker as the bus daemon, and need libdbus, will have
> >>> to enable both, see below.
> >>>
> >>> There are two cases:
> >>>
> >>>    1. original dbus disabled
> >>>
> >>>       Here, we install the config files and systemd socket activation
> >>>       units; dbus-broker provides the system and sessions bus daemons.
> >>>
> >>>       In this case, libdbus is not available.
> >>>
> >>>    2. original dbus enabled
> >>>
> >>>       In this case, we do not install the config files and systemd
> socket
> >>>       activation units, or define a user: they all are provided by the
> >>>       original dbus, and we piggy-back on those.
> >>>
> >>>       In this situation, the default system and sessions message bus
> are
> >>>       the original dbus, and libdbus is available; dbus-broker is not
> >>>       enabled.
> >>>
> >>>       So far, we believe it would be over-engineered to provide a way
> >>>       to allow choosing the bus daemon in the configuraiton. However,
> >>>       users may opt-in to use dbus-broker in a few ways:
> >>>         - at build-time: by calling systemctl enable/disable from a
> >>>           post-build script (preferred), or by providing drop-in units
> >>>           or presets in an overlay (less preferred) or custom skeleton
> >>>           (as a last resort),
> >>>         - at runtime (on a RW filesystem): by calling systemctl
> >>>           enable/disable
> >>
> >>    I don't know... To me it seems logical that if both are enabled,
> that you use
> >> dbus-broker for the bus and only use original dbus for libdbus.
> >
> > Would be fine by me, back then most distros required you to
> > manually enable dbus-broker, now it seems they shift to using
> > it by default if installed.
>
>   Since we anyway already have the infrastructure to automatically enable
> it if
> dbus is not included, it should be easy to do that even if dbus is
> included.
>
> >>    So to me the proper approach seems to change dbus itself so the
> daemon is
> >> optional, i.e. only libdbus is installed if the daemon is not enabled,
> similar
> >> to e.g. libcurl. BR2_PACKAGE_DBUS_DAEMON should default to y because
> that's what
> >> most people want. We'd have to go through existing packages to check if
> they
> >> depend on libdbus or on the daemon - mostly it will be the first. If
> there is a
> >> package that really needs the daemon (I don't actually think so), then
> we might
> >> need to introduce a virtual package for the daemon. Regardless,
> dbus-broker
> >> should depend on !BR2_PACKAGE_DBUS_DAEMON.
>
>   Looking more detailed at it, this seems too complicated. dbus doesn't
> offer a
> way to install only the library. Also in terms of rootfs size, the only
> difference is the dbus-daemon and dbus-launch binaries, plus a few config
> files.
> Not really sufficient to make it worth it.
>
>   What I will do, I think, is to include logic in dbus to remove the
> activation
> units (both the service and the socket) when dbus-broker is enabled. It is
> slightly messy because dbus.mk and dbus-broker.mk become fairly tightly
> woven
> together, but I think it's worth it from a usability perspective.
>

Sounds messy too,
I would rather have a dbus-common package that includes the socket an
config files (and creates the user if necessary).

That package would download dbus, but not build it, instead just copy over
those files.
Kinda like util-linux-libs


> > Debian does something similar, including splitting of the xml config
> files
> > and actual daemons into their own packages.
> >
> > see [1].
> >
> >>> Note about the user: the path to the system bus socket is a so-called
> >>> "well-known location": it is expected to be there, by spec. Moving it
> >>> elsewhere is going to break existing programs. So, the user running the
> >>> system bus daemon must be able to create that socket.
> >>>
> >>> As we may have two packages providing a system bus daemon, they have to
> >>> be both able to create the socket, and thus must both be able to write
> >>> in the directory containing the socket. And since they can be switched
> >>> at runtime, they must be running as the same user.
> >>>
> >>> We can't just reference the original dbus user, so we duplicate the
> >>> entry. What is important, is that the user be named 'dbus', as that's
> >>> what we use in both cases.
> >>
> >>    If it's a virtual package, then the user could be created by the
> virtual
> >> package itself.
>
>   It won't be a virtual package, so no longer relevant.
>
>
> > with systemd you probably dont even need a real user for the isolation
> > benefits.
> > So maybe this would just be necessary if dbus utilities are used,
> > you can also just let systemd create that user dynamically:
> >
> > [Service]
> > ...
> > User=dbus
> > Group=dbus > DynamicUser=true
>
>   If we do this both in the dbus and the dbus-broker units, then indeed we
> can
> remove the dbus user.
>

AFAIR the reason for the dbus to be a system user is that dbus-launch can
setuid into it.
So it only works without system user if dbus-launch is not used.
Dbus-broker delegates this functionality to system (dbus activation)


>   If I add this just to dbus-broker, but dbus still creates a static user,
> is
> this going to give a problem for systemd? I.e. does systemd support a
> DynamicUser=true if the user exists already statically? I think so...
>

Think so too.


>   Regards,
>   Arnout
>
> > ExecStart=!/usr/bin/dbus-broker-launch --scope system --audit
> > ExecReload=!/usr/bin/busctl call org.freedesktop.DBus
> > /org/freedesktop/DBus org.freedesktop.DBus ReloadConfig
>
> [snip]
>

Norbert

>

[-- Attachment #1.2: Type: text/html, Size: 10179 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot