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

[Arnout Vandecappelle <arnout@mind.be>]

On 27/07/2022 19:31, Norbert Lange wrote:
> 
> 
> Arnout Vandecappelle <arnout@mind.be <mailto: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 <mailto:arnout@mind.be>>:
[snip]
>      >>    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 <http://dbus.mk> and dbus-broker.mk
>     <http://dbus-broker.mk> become fairly tightly woven
>     together, but I think it's worth it from a usability perspective.
> 
> 
> Sounds messy too,

  Agreed. But the only unmessy thing that I found so far is to not use 
dbus-broker at all if original dbus is selected, and I think that that pretty 
much defeats the purpose of including dbus-broker.

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

  That is a good idea. However, it only works for the two dbus configuration 
files, not for the systemd units, so it only solves half of the mess. And the 
added benefit is not that great. Also, they don't change very often any more 
upstream (the last change is from 12/21, before that it's 12/17). So in the end 
we decided not to go for dbus-common.


> 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)

  Well, the service file still calls dbus-broker-launch, which I guess does 
setuid because the upstream service file doesn't have any User= or Group=

  I think we'll just stick to what we have now, and keep the upstream service 
file rather than hacking our own...

  Regards,
  Arnout

> 
> 
>        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
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot