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

[Norbert Lange <nolange79@gmail.com>]

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

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

>
>
> 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 meant Dbus-launch, dbus-broker-launch *does not use setuid* which depends
on filesystem/inode permissions and uid.
If you prefix a ! In the service file dbus-broker-launch will be run as
root, and since this is the only way the executable is used (unlike dbus)
the dynamic user uid is enough.

Hence dbus-broker-launch works with random/dynamic uids, while dbus-launch
needs a stable one.


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

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

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

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