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

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

[Norbert Lange]

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

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.

Finally, the licensing terms are pretty trivial for dbus-broker itself,
but it makes use of third-party code that it inherits as git submodules
(that are bundled in the release archive). Thus the licensing is a bit
convoluted... The third-party codes claim to be licensed as "Apache-2.0
and LGP-2.1+" in their AUTHORS files, but at the same time claim
"**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
individual source files (that are used) do not seem to have any
licensing header to clarify the situation. So we represent the situation
with "Apache-2.0 and/or LGPL-2.1+".

Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
  - don't select systemd; depend on it instead
  - only install config files and systemd units without original dbus
  - install a user to run the message bus as
  - fix licensing info
  - entirely reword and extend the commit log
  - add myself to DEVELOPERS as well
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

---
Changes v5 -> v6  (Norbert, respinning after Yann):
  - bump version to v29
  - Linux 4.17 is now a hard requirement, drop passing option
  - sync dbus_broker user to dbus package ( home = /run/dbus )

Changes v4 -> v5  (Yann, after review by Norbert):
  - define the user to run as directly in system.conf
  - as a consequence, drop the unit drop-in
  - add myself to DEVELOPERS as well

Changes v3 -> v4  (Yann, respining after review by Norbert):
  - drop the non-systemd case
  - drop the launcher option
  - reinstate BR2_COREUTILS_HOST_DEPENDENCY and ln --relative
  - reinstate the user, explain it

Changes v2 -> v3  (Norbert, respinning after Yann):
  - add an own config entry for dbus-broker-launch
    enabled by default if systemd init is used
  - undo BR2_COREUTILS_HOST_DEPENDENCY
  - undo adding dbus user - never used by this package
  - add condtional audit dependency
  - cleanup conditional logic a bit

Changes v1 -> v2 (Yann):
  - make launcher conditional
  - don't select systemd; don't depend on it either
  - don't install systemd units without systemd
  - only install config files and systemd units wihtout original dbus
  - rename hooks with meaningful names
  - fix licensing info
  - entirely reword and extend the commit log
---
 DEVELOPERS                           |   2 +
 package/Config.in                    |   1 +
 package/dbus-broker/Config.in        |  23 +++++
 package/dbus-broker/dbus-broker.hash |   3 +
 package/dbus-broker/dbus-broker.mk   |  71 ++++++++++++++++
 package/dbus-broker/dbus.socket      |   5 ++
 package/dbus-broker/session.conf     |  65 ++++++++++++++
 package/dbus-broker/system.conf      | 123 +++++++++++++++++++++++++++
 8 files changed, 293 insertions(+)
 create mode 100644 package/dbus-broker/Config.in
 create mode 100644 package/dbus-broker/dbus-broker.hash
 create mode 100644 package/dbus-broker/dbus-broker.mk
 create mode 100644 package/dbus-broker/dbus.socket
 create mode 100644 package/dbus-broker/session.conf
 create mode 100644 package/dbus-broker/system.conf

diff --git a/DEVELOPERS b/DEVELOPERS
index ed65c74319..02ba98e410 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -2111,6 +2111,7 @@ F:	package/tpm-tools/
 F:	package/trousers/
 
 N:	Norbert Lange <nolange79@gmail.com>
+F:	package/dbus-broker/
 F:	package/systemd/
 F:	package/tcf-agent/
 
@@ -2914,6 +2915,7 @@ F:	package/asterisk/
 F:	package/cegui/
 F:	package/dahdi-linux/
 F:	package/dahdi-tools/
+F:	package/dbus-broker/
 F:	package/dtc/
 F:	package/dtv-scan-tables/
 F:	package/dvb-apps/
diff --git a/package/Config.in b/package/Config.in
index 5e01187b83..ebc64a25f2 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -459,6 +459,7 @@ endmenu
 	source "package/dahdi-tools/Config.in"
 	source "package/davinci-bootcount/Config.in"
 	source "package/dbus/Config.in"
+	source "package/dbus-broker/Config.in"
 	source "package/dbus-cpp/Config.in"
 	source "package/dbus-glib/Config.in"
 	source "package/dbus-python/Config.in"
diff --git a/package/dbus-broker/Config.in b/package/dbus-broker/Config.in
new file mode 100644
index 0000000000..c7206232da
--- /dev/null
+++ b/package/dbus-broker/Config.in
@@ -0,0 +1,23 @@
+config BR2_PACKAGE_DBUS_BROKER
+	bool "dbus-broker"
+	depends on BR2_USE_MMU
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_17
+	depends on BR2_PACKAGE_SYSTEMD
+	select BR2_PACKAGE_EXPAT
+	help
+	  Linux D-Bus Message Broker.
+
+	  The dbus-broker project is an implementation of a message bus
+	  as defined by the D-Bus specification. Its aim is to provide
+	  high performance and reliability, while keeping compatibility
+	  to the D-Bus reference implementation.
+
+	  It is exclusively written for Linux systems, and makes use of
+	  many modern features provided by recent linux kernel releases.
+
+	  https://github.com/bus1/dbus-broker/wiki
+
+comment "dbusbroker needs systemd and a toolchain w/ threads"
+	depends on BR2_USE_MMU
+	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_SYSTEMD
diff --git a/package/dbus-broker/dbus-broker.hash b/package/dbus-broker/dbus-broker.hash
new file mode 100644
index 0000000000..26ebab7ac1
--- /dev/null
+++ b/package/dbus-broker/dbus-broker.hash
@@ -0,0 +1,3 @@
+# Locally calculated
+sha256  4eca425db52b7ab1027153e93fea9b3f11759db9e93ffbf88759b73ddfb8026a  dbus-broker-29.tar.xz
+sha256  3cda3630283eda0eab825abe5ac84d191248c6b3fe1c232a118124959b96c6a4  LICENSE
diff --git a/package/dbus-broker/dbus-broker.mk b/package/dbus-broker/dbus-broker.mk
new file mode 100644
index 0000000000..547b79eb84
--- /dev/null
+++ b/package/dbus-broker/dbus-broker.mk
@@ -0,0 +1,71 @@
+################################################################################
+#
+# dbus-broker
+#
+################################################################################
+
+DBUS_BROKER_VERSION = 29
+DBUS_BROKER_SOURCE = dbus-broker-$(DBUS_BROKER_VERSION).tar.xz
+DBUS_BROKER_SITE = https://github.com/bus1/dbus-broker/releases/download/v$(DBUS_BROKER_VERSION)
+
+# For the third-party code, the licensing legla-info is inconsistent between
+# the AUTHORS and README, so keep both
+DBUS_BROKER_LICENSE = \
+	Apache-2.0, \
+	Apache-2.0 and/or LGPL-2.1+ (c-dvar, c-ini, c-list, c-rbtree, c-shquote, c-stdaux, c-utf8)
+DBUS_BROKER_LICENSE_FILES = \
+	LICENSE \
+	subprojects/c-dvar/AUTHORS subprojects/c-dvar/README.md \
+	subprojects/c-ini/AUTHORS subprojects/c-ini/README.md \
+	subprojects/c-list/AUTHORS subprojects/c-list/README.md \
+	subprojects/c-rbtree/AUTHORS subprojects/c-rbtree/README.md \
+	subprojects/c-shquote/AUTHORS subprojects/c-shquote/README.md \
+	subprojects/c-stdaux/AUTHORS subprojects/c-stdaux/README.md \
+	subprojects/c-utf8/AUTHORS subprojects/c-utf8/README.md
+
+DBUS_BROKER_DEPENDENCIES = expat systemd
+DBUS_BROKER_CONF_OPTS = -Dlauncher=true
+
+ifeq ($(BR2_PACKAGE_AUDIT),y)
+DBUS_BROKER_DEPENDENCIES += audit
+DBUS_BROKER_CONF_OPTS += -Daudit=true
+else
+DBUS_BROKER_CONF_OPTS += -Daudit=false
+endif
+
+ifeq ($(BR2_PACKAGE_LIBSELINUX),y)
+DBUS_BROKER_DEPENDENCIES += libselinux
+DBUS_BROKER_CONF_OPTS += -Dselinux=true
+else
+DBUS_BROKER_CONF_OPTS += -Dselinux=false
+endif
+
+# We must be using the same user as the original dbus, so we can share
+# the home directory and create a socket there. As a consequence, the
+# username and groupname must be dbus:dbus, and they both need to have
+# the same home.
+define DBUS_BROKER_USERS
+	dbus -1 dbus -1 * /run/dbus - dbus DBus messagebus user
+endef
+
+# Only install units for system bus daemon socket if original dbus is not present
+# Only install config and service files if original dbus is not present
+#
+# Note: BR2_COREUTILS_HOST_DEPENDENCY to be able to use ln --relative
+ifeq ($(BR2_PACKAGE_DBUS),)
+DBUS_BROKER_DEPENDENCIES += $(BR2_COREUTILS_HOST_DEPENDENCY)
+
+define DBUS_BROKER_INSTALL_INIT_SYSTEMD
+	$(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/session.conf \
+		$(TARGET_DIR)/usr/share/dbus-1/session.conf
+	$(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/system.conf \
+		$(TARGET_DIR)/usr/share/dbus-1/system.conf
+	$(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/dbus.socket \
+		$(TARGET_DIR)/usr/lib/systemd/system/dbus.socket
+	$(HOST_MAKE_ENV) ln -sf --relative \
+		$(TARGET_DIR)/usr/lib/systemd/system/dbus.socket \
+		$(TARGET_DIR)/usr/lib/systemd/system/sockets.target.wants/dbus.socket
+endef
+endif # !BR2_PACKAGE_DBUS
+
+$(eval $(meson-package))
diff --git a/package/dbus-broker/dbus.socket b/package/dbus-broker/dbus.socket
new file mode 100644
index 0000000000..5c373cf450
--- /dev/null
+++ b/package/dbus-broker/dbus.socket
@@ -0,0 +1,5 @@
+[Unit]
+Description=D-Bus System Message Bus Socket
+
+[Socket]
+ListenStream=/run/dbus/system_bus_socket
diff --git a/package/dbus-broker/session.conf b/package/dbus-broker/session.conf
new file mode 100644
index 0000000000..e4758fa218
--- /dev/null
+++ b/package/dbus-broker/session.conf
@@ -0,0 +1,65 @@
+<!-- This configuration file controls the per-user-login-session message bus.
+     Add a session-local.conf and edit that rather than changing this
+     file directly. -->
+
+<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
+ "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
+<busconfig>
+  <!-- Our well-known bus type, don't change this -->
+  <type>session</type>
+
+  <!-- If we fork, keep the user's original umask to avoid affecting
+       the behavior of child processes. -->
+  <keep_umask/>
+
+  <standard_session_servicedirs />
+
+  <policy context="default">
+    <!-- Allow everything to be sent -->
+    <allow send_destination="*" eavesdrop="true"/>
+    <!-- Allow everything to be received -->
+    <allow eavesdrop="true"/>
+    <!-- Allow anyone to own anything -->
+    <allow own="*"/>
+  </policy>
+
+  <!-- Config files are placed here that among other things,
+       further restrict the above policy for specific services. -->
+  <includedir>session.d</includedir>
+
+  <includedir>/etc/dbus-1/session.d</includedir>
+
+  <!-- This is included last so local configuration can override what's
+       in this standard file -->
+  <include ignore_missing="yes">/etc/dbus-1/session-local.conf</include>
+
+  <include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
+
+  <!-- For the session bus, override the default relatively-low limits
+       with essentially infinite limits, since the bus is just running
+       as the user anyway, using up bus resources is not something we need
+       to worry about. In some cases, we do set the limits lower than
+       "all available memory" if exceeding the limit is almost certainly a bug,
+       having the bus enforce a limit is nicer than a huge memory leak. But the
+       intent is that these limits should never be hit. -->
+
+  <!-- the memory limits are 1G instead of say 4G because they can't exceed 32-bit signed int max -->
+  <limit name="max_incoming_bytes">1000000000</limit>
+  <limit name="max_incoming_unix_fds">250000000</limit>
+  <limit name="max_outgoing_bytes">1000000000</limit>
+  <limit name="max_outgoing_unix_fds">250000000</limit>
+  <limit name="max_message_size">1000000000</limit>
+  <!-- We do not override max_message_unix_fds here since the in-kernel
+       limit is also relatively low -->
+  <limit name="service_start_timeout">120000</limit>
+  <limit name="auth_timeout">240000</limit>
+  <limit name="pending_fd_timeout">150000</limit>
+  <limit name="max_completed_connections">100000</limit>
+  <limit name="max_incomplete_connections">10000</limit>
+  <limit name="max_connections_per_user">100000</limit>
+  <limit name="max_pending_service_starts">10000</limit>
+  <limit name="max_names_per_connection">50000</limit>
+  <limit name="max_match_rules_per_connection">50000</limit>
+  <limit name="max_replies_per_connection">50000</limit>
+
+</busconfig>
diff --git a/package/dbus-broker/system.conf b/package/dbus-broker/system.conf
new file mode 100644
index 0000000000..4b17fbd90e
--- /dev/null
+++ b/package/dbus-broker/system.conf
@@ -0,0 +1,123 @@
+<!-- This configuration file controls the systemwide message bus.
+     Add a system-local.conf and edit that rather than changing this
+     file directly. -->
+
+<!-- Note that there are any number of ways you can hose yourself
+     security-wise by screwing up this file; in particular, you
+     probably don't want to listen on any more addresses, add any more
+     auth mechanisms, run as a different user, etc. -->
+
+<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
+ "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
+<busconfig>
+
+  <!-- Our well-known bus type, do not change this -->
+  <type>system</type>
+
+  <!-- Fork into daemon mode -->
+  <fork/>
+
+  <!-- Run as special user -->
+  <user>dbus</user>
+
+  <!-- We use system service launching using a helper -->
+  <standard_system_servicedirs/>
+
+  <!-- Enable logging to syslog -->
+  <syslog/>
+
+  <policy context="default">
+    <!-- All users can connect to system bus -->
+    <allow user="*"/>
+
+    <!-- Holes must be punched in service configuration files for
+         name ownership and sending method calls -->
+    <deny own="*"/>
+    <deny send_type="method_call"/>
+
+    <!-- Signals and reply messages (method returns, errors) are allowed
+         by default -->
+    <allow send_type="signal"/>
+    <allow send_requested_reply="true" send_type="method_return"/>
+    <allow send_requested_reply="true" send_type="error"/>
+
+    <!-- All messages may be received by default -->
+    <allow receive_type="method_call"/>
+    <allow receive_type="method_return"/>
+    <allow receive_type="error"/>
+    <allow receive_type="signal"/>
+
+    <!-- Allow anyone to talk to the message bus -->
+    <allow send_destination="org.freedesktop.DBus"
+           send_interface="org.freedesktop.DBus" />
+    <allow send_destination="org.freedesktop.DBus"
+           send_interface="org.freedesktop.DBus.Introspectable"/>
+    <allow send_destination="org.freedesktop.DBus"
+           send_interface="org.freedesktop.DBus.Properties"/>
+    <!-- But disallow some specific bus services -->
+    <deny send_destination="org.freedesktop.DBus"
+          send_interface="org.freedesktop.DBus"
+          send_member="UpdateActivationEnvironment"/>
+    <deny send_destination="org.freedesktop.DBus"
+          send_interface="org.freedesktop.DBus.Debug.Stats"/>
+    <deny send_destination="org.freedesktop.DBus"
+          send_interface="org.freedesktop.systemd1.Activator"/>
+  </policy>
+
+  <!-- Only systemd, which runs as root, may report activation failures. -->
+  <policy user="root">
+    <allow send_destination="org.freedesktop.DBus"
+           send_interface="org.freedesktop.systemd1.Activator"/>
+  </policy>
+
+  <!-- root may monitor the system bus. -->
+  <policy user="root">
+    <allow send_destination="org.freedesktop.DBus"
+           send_interface="org.freedesktop.DBus.Monitoring"/>
+  </policy>
+
+  <!-- If the Stats interface was enabled at compile-time, root may use it.
+       Copy this into system.local.conf or system.d/*.conf if you want to
+       enable other privileged users to view statistics and debug info -->
+  <policy user="root">
+    <allow send_destination="org.freedesktop.DBus"
+           send_interface="org.freedesktop.DBus.Debug.Stats"/>
+  </policy>
+
+
+  <!-- The defaults for these limits are hard-coded in dbus-daemon.
+       Some clarifications:
+       Times are in milliseconds (ms); 1000ms = 1 second
+       133169152 bytes = 127 MiB
+       33554432 bytes = 32 MiB
+       150000ms = 2.5 minutes -->
+  <!-- <limit name="max_incoming_bytes">133169152</limit> -->
+  <!-- <limit name="max_incoming_unix_fds">64</limit> -->
+  <!-- <limit name="max_outgoing_bytes">133169152</limit> -->
+  <!-- <limit name="max_outgoing_unix_fds">64</limit> -->
+  <!-- <limit name="max_message_size">33554432</limit> -->
+  <!-- <limit name="max_message_unix_fds">16</limit> -->
+  <!-- <limit name="service_start_timeout">25000</limit> -->
+  <!-- <limit name="auth_timeout">5000</limit> -->
+  <!-- <limit name="pending_fd_timeout">150000</limit> -->
+  <!-- <limit name="max_completed_connections">2048</limit> -->
+  <!-- <limit name="max_incomplete_connections">64</limit> -->
+  <!-- <limit name="max_connections_per_user">256</limit> -->
+  <!-- <limit name="max_pending_service_starts">512</limit> -->
+  <!-- <limit name="max_names_per_connection">512</limit> -->
+  <!-- <limit name="max_match_rules_per_connection">512</limit> -->
+  <!-- <limit name="max_replies_per_connection">128</limit> -->
+
+  <!-- Config files are placed here that among other things, punch
+       holes in the above policy for specific services. -->
+  <includedir>system.d</includedir>
+
+  <includedir>/etc/dbus-1/system.d</includedir>
+
+  <!-- This is included last so local configuration can override what's
+       in this standard file -->
+  <include ignore_missing="yes">/etc/dbus-1/system-local.conf</include>
+
+  <include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
+
+</busconfig>
-- 
2.34.1

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

[Buildroot] [PATCH v6 2/4] package/systemd: do not force dbus if dbus-broker is available

[Norbert Lange]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

dbus-broker fits the bill as a message bus daemon, so only enable the
original dbus if dbus-broker is not enabled.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
---
 package/systemd/Config.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/systemd/Config.in b/package/systemd/Config.in
index cc0736561e..1c227bb07f 100644
--- a/package/systemd/Config.in
+++ b/package/systemd/Config.in
@@ -26,7 +26,7 @@ menuconfig BR2_PACKAGE_SYSTEMD
 	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5
 	depends on BR2_HOST_GCC_AT_LEAST_5 # host-systemd
 	select BR2_PACKAGE_HAS_UDEV
-	select BR2_PACKAGE_DBUS # runtime dependency only
+	select BR2_PACKAGE_DBUS if !BR2_PACKAGE_DBUS_BROKER # runtime
 	select BR2_PACKAGE_LIBCAP
 	select BR2_PACKAGE_UTIL_LINUX
 	select BR2_PACKAGE_UTIL_LINUX_LIBS
-- 
2.34.1

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

[Buildroot] [PATCH v6 3/4] support/testsuite: de-duplicate the systemd runtime tests

[Norbert Lange]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

Of all the systemd init tests, only one does some additional tests, and
for just this lone wolf, we duplicate the test function.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
---
 support/testing/tests/init/test_systemd.py | 32 ++++++++--------------
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/support/testing/tests/init/test_systemd.py b/support/testing/tests/init/test_systemd.py
index f0cc52bac8..80c6776f59 100644
--- a/support/testing/tests/init/test_systemd.py
+++ b/support/testing/tests/init/test_systemd.py
@@ -21,8 +21,9 @@ class InitSystemSystemdBase(InitSystemBase):
         # BR2_TARGET_ROOTFS_TAR is not set
         """.format(infra.filepath("conf/binfmt-misc-kernel-fragment.config"))
 
-    def check_init(self):
-        super(InitSystemSystemdBase, self).check_init("/lib/systemd/systemd")
+    def check_systemd(self, fs):
+        self.start_emulator(fs, "zImage", "vexpress-v2p-ca9")
+        self.check_init("/lib/systemd/systemd")
 
         # Test all units are OK
         output, _ = self.emulator.run("systemctl --no-pager --failed --no-legend")
@@ -35,6 +36,9 @@ class InitSystemSystemdBase(InitSystemBase):
         output, _ = self.emulator.run("journalctl --no-pager --lines 1 --quiet")
         self.assertEqual(len(output), 1)
 
+        # Check the network is up
+        self.check_network("eth0")
+
 
 class TestInitSystemSystemdRoNetworkd(InitSystemSystemdBase):
     config = InitSystemSystemdBase.config + \
@@ -46,9 +50,7 @@ class TestInitSystemSystemdRoNetworkd(InitSystemSystemdBase):
         """.format(infra.filepath("tests/init/systemd-factory"))
 
     def test_run(self):
-        self.start_emulator("squashfs", "zImage", "vexpress-v2p-ca9")
-        self.check_init()
-        self.check_network("eth0")
+        self.check_systemd("squashfs")
 
         # This one must be executed on the target, to check that
         # the factory feature works as expected
@@ -65,9 +67,7 @@ class TestInitSystemSystemdRwNetworkd(InitSystemSystemdBase):
         """
 
     def test_run(self):
-        self.start_emulator("ext2", "zImage", "vexpress-v2p-ca9")
-        self.check_init()
-        self.check_network("eth0")
+        self.check_systemd("ext2")
 
 
 class TestInitSystemSystemdRoIfupdown(InitSystemSystemdBase):
@@ -80,9 +80,7 @@ class TestInitSystemSystemdRoIfupdown(InitSystemSystemdBase):
         """
 
     def test_run(self):
-        self.start_emulator("squashfs", "zImage", "vexpress-v2p-ca9")
-        self.check_init()
-        self.check_network("eth0")
+        self.check_systemd("squashfs")
 
 
 class TestInitSystemSystemdRwIfupdown(InitSystemSystemdBase):
@@ -94,9 +92,7 @@ class TestInitSystemSystemdRwIfupdown(InitSystemSystemdBase):
         """
 
     def test_run(self):
-        self.start_emulator("ext2", "zImage", "vexpress-v2p-ca9")
-        self.check_init()
-        self.check_network("eth0")
+        self.check_systemd("ext2")
 
 
 class TestInitSystemSystemdRoFull(InitSystemSystemdBase):
@@ -125,9 +121,7 @@ class TestInitSystemSystemdRoFull(InitSystemSystemdBase):
         """
 
     def test_run(self):
-        self.start_emulator("squashfs", "zImage", "vexpress-v2p-ca9")
-        self.check_init()
-        self.check_network("eth0")
+        self.check_systemd("squashfs")
 
 
 class TestInitSystemSystemdRwFull(InitSystemSystemdBase):
@@ -155,6 +149,4 @@ class TestInitSystemSystemdRwFull(InitSystemSystemdBase):
         """
 
     def test_run(self):
-        self.start_emulator("ext2", "zImage", "vexpress-v2p-ca9")
-        self.check_init()
-        self.check_network("eth0")
+        self.check_systemd("ext2")
-- 
2.34.1

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

Re: [Buildroot] [PATCH v6 3/4] support/testsuite: de-duplicate the systemd runtime tests

[Arnout Vandecappelle]

On 09/01/2022 23:16, Norbert Lange wrote:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> Of all the systemd init tests, only one does some additional tests, and
> for just this lone wolf, we duplicate the test function.
> 
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

  Applied to master, thanks.

  Regards,
  Arnout

> ---
>   support/testing/tests/init/test_systemd.py | 32 ++++++++--------------
>   1 file changed, 12 insertions(+), 20 deletions(-)
> 
> diff --git a/support/testing/tests/init/test_systemd.py b/support/testing/tests/init/test_systemd.py
> index f0cc52bac8..80c6776f59 100644
> --- a/support/testing/tests/init/test_systemd.py
> +++ b/support/testing/tests/init/test_systemd.py
> @@ -21,8 +21,9 @@ class InitSystemSystemdBase(InitSystemBase):
>           # BR2_TARGET_ROOTFS_TAR is not set
>           """.format(infra.filepath("conf/binfmt-misc-kernel-fragment.config"))
>   
> -    def check_init(self):
> -        super(InitSystemSystemdBase, self).check_init("/lib/systemd/systemd")
> +    def check_systemd(self, fs):
> +        self.start_emulator(fs, "zImage", "vexpress-v2p-ca9")
> +        self.check_init("/lib/systemd/systemd")
>   
>           # Test all units are OK
>           output, _ = self.emulator.run("systemctl --no-pager --failed --no-legend")
> @@ -35,6 +36,9 @@ class InitSystemSystemdBase(InitSystemBase):
>           output, _ = self.emulator.run("journalctl --no-pager --lines 1 --quiet")
>           self.assertEqual(len(output), 1)
>   
> +        # Check the network is up
> +        self.check_network("eth0")
> +
>   
>   class TestInitSystemSystemdRoNetworkd(InitSystemSystemdBase):
>       config = InitSystemSystemdBase.config + \
> @@ -46,9 +50,7 @@ class TestInitSystemSystemdRoNetworkd(InitSystemSystemdBase):
>           """.format(infra.filepath("tests/init/systemd-factory"))
>   
>       def test_run(self):
> -        self.start_emulator("squashfs", "zImage", "vexpress-v2p-ca9")
> -        self.check_init()
> -        self.check_network("eth0")
> +        self.check_systemd("squashfs")
>   
>           # This one must be executed on the target, to check that
>           # the factory feature works as expected
> @@ -65,9 +67,7 @@ class TestInitSystemSystemdRwNetworkd(InitSystemSystemdBase):
>           """
>   
>       def test_run(self):
> -        self.start_emulator("ext2", "zImage", "vexpress-v2p-ca9")
> -        self.check_init()
> -        self.check_network("eth0")
> +        self.check_systemd("ext2")
>   
>   
>   class TestInitSystemSystemdRoIfupdown(InitSystemSystemdBase):
> @@ -80,9 +80,7 @@ class TestInitSystemSystemdRoIfupdown(InitSystemSystemdBase):
>           """
>   
>       def test_run(self):
> -        self.start_emulator("squashfs", "zImage", "vexpress-v2p-ca9")
> -        self.check_init()
> -        self.check_network("eth0")
> +        self.check_systemd("squashfs")
>   
>   
>   class TestInitSystemSystemdRwIfupdown(InitSystemSystemdBase):
> @@ -94,9 +92,7 @@ class TestInitSystemSystemdRwIfupdown(InitSystemSystemdBase):
>           """
>   
>       def test_run(self):
> -        self.start_emulator("ext2", "zImage", "vexpress-v2p-ca9")
> -        self.check_init()
> -        self.check_network("eth0")
> +        self.check_systemd("ext2")
>   
>   
>   class TestInitSystemSystemdRoFull(InitSystemSystemdBase):
> @@ -125,9 +121,7 @@ class TestInitSystemSystemdRoFull(InitSystemSystemdBase):
>           """
>   
>       def test_run(self):
> -        self.start_emulator("squashfs", "zImage", "vexpress-v2p-ca9")
> -        self.check_init()
> -        self.check_network("eth0")
> +        self.check_systemd("squashfs")
>   
>   
>   class TestInitSystemSystemdRwFull(InitSystemSystemdBase):
> @@ -155,6 +149,4 @@ class TestInitSystemSystemdRwFull(InitSystemSystemdBase):
>           """
>   
>       def test_run(self):
> -        self.start_emulator("ext2", "zImage", "vexpress-v2p-ca9")
> -        self.check_init()
> -        self.check_network("eth0")
> +        self.check_systemd("ext2")
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v6 4/4] support/run-test: add test for systemd using dbus-broker

[Norbert Lange]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

Add four new tests for systemd (rw and ro in each case):
  - use dbus-broker instead of the original dbus
  - use the original dbus, with dbus-broker installed

The first two extend the existing IfUpDown test cases by just enabling
dbus-broker; the second ones extend this further, by explicitly enabling
the original dbus.

For one of the tests, we overload the test_run() function to test that
the dbus-broker daemon is indeed running as root. We need not replicate
that check in the other dbus-broker-only test, and it does not make
sense to test that in tests that have the original dbus enabled.

Presence of the original dbus and dbus-broker on the same system is
valid: the original dbus is used as the default system bus daemon. We do
not test switching between the two at runtime, though as this is really
too corner-case specific. We just test to ensure the original dbus
system bus daemon is not impacted by the presence of dbus-broker.

Note: the 'full' test-case enables all systemd options, and some of them
do pull the original dbus package, so we can't use that to test the
integration of dbus-broker; instead, we extend the ifupdown case, which
does not enable the original dbus.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
---
 support/testing/tests/init/test_systemd.py | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/support/testing/tests/init/test_systemd.py b/support/testing/tests/init/test_systemd.py
index 80c6776f59..80d172e5e2 100644
--- a/support/testing/tests/init/test_systemd.py
+++ b/support/testing/tests/init/test_systemd.py
@@ -83,6 +83,29 @@ class TestInitSystemSystemdRoIfupdown(InitSystemSystemdBase):
         self.check_systemd("squashfs")
 
 
+class TestInitSystemSystemdRoIfupdownDbusbroker(TestInitSystemSystemdRoIfupdown):
+    config = TestInitSystemSystemdRoIfupdown.config + \
+        """
+        BR2_PACKAGE_DBUS_BROKER=y
+        """
+
+    def test_run(self):
+        # Parent class' test_run() method does exactly that, no more:
+        self.check_systemd("squashfs")
+
+        # Check that the dbus-broker daemon is running as non-root
+        cmd = "find /proc/$(pidof dbus-broker) -maxdepth 1 -name exe -user dbus"
+        out, _ = self.emulator.run(cmd)
+        self.assertEqual(len(out), 1)
+
+
+class TestInitSystemSystemdRoIfupdownDbusbrokerDbus(TestInitSystemSystemdRoIfupdownDbusbroker):
+    config = TestInitSystemSystemdRoIfupdownDbusbroker.config + \
+        """
+        BR2_PACKAGE_DBUS=y
+        """
+
+
 class TestInitSystemSystemdRwIfupdown(InitSystemSystemdBase):
     config = InitSystemSystemdBase.config + \
         """
@@ -95,6 +118,20 @@ class TestInitSystemSystemdRwIfupdown(InitSystemSystemdBase):
         self.check_systemd("ext2")
 
 
+class TestInitSystemSystemdRwIfupdownDbusbroker(TestInitSystemSystemdRwIfupdown):
+    config = TestInitSystemSystemdRwIfupdown.config + \
+        """
+        BR2_PACKAGE_DBUS_BROKER=y
+        """
+
+
+class TestInitSystemSystemdRwIfupdownDbusbrokerDbus(TestInitSystemSystemdRwIfupdownDbusbroker):
+    config = TestInitSystemSystemdRwIfupdownDbusbroker.config + \
+        """
+        BR2_PACKAGE_DBUS=y
+        """
+
+
 class TestInitSystemSystemdRoFull(InitSystemSystemdBase):
     config = InitSystemSystemdBase.config + \
         """
-- 
2.34.1

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

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

[Arnout Vandecappelle]

  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.

  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.


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


> Finally, the licensing terms are pretty trivial for dbus-broker itself,
> but it makes use of third-party code that it inherits as git submodules
> (that are bundled in the release archive). 

  Ugh, bundling...

> Thus the licensing is a bit
> convoluted... The third-party codes claim to be licensed as "Apache-2.0
> and LGP-2.1+" in their AUTHORS files, but at the same time claim
> "**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
> individual source files (that are used) do not seem to have any
> licensing header to clarify the situation. So we represent the situation
> with "Apache-2.0 and/or LGPL-2.1+".

  That's rather f**d than convoluted :-)

> 
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> [yann.morin.1998@free.fr:
>    - don't select systemd; depend on it instead
>    - only install config files and systemd units without original dbus
>    - install a user to run the message bus as
>    - fix licensing info
>    - entirely reword and extend the commit log
>    - add myself to DEVELOPERS as well
> ]
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

[snip]
> diff --git a/package/dbus-broker/Config.in b/package/dbus-broker/Config.in
> new file mode 100644
> index 0000000000..c7206232da
> --- /dev/null
> +++ b/package/dbus-broker/Config.in
> @@ -0,0 +1,23 @@
> +config BR2_PACKAGE_DBUS_BROKER
> +	bool "dbus-broker"
> +	depends on BR2_USE_MMU
> +	depends on BR2_TOOLCHAIN_HAS_THREADS
> +	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_17
> +	depends on BR2_PACKAGE_SYSTEMD
> +	select BR2_PACKAGE_EXPAT
> +	help
> +	  Linux D-Bus Message Broker.
> +
> +	  The dbus-broker project is an implementation of a message bus
> +	  as defined by the D-Bus specification. Its aim is to provide
> +	  high performance and reliability, while keeping compatibility
> +	  to the D-Bus reference implementation.
> +
> +	  It is exclusively written for Linux systems, and makes use of
> +	  many modern features provided by recent linux kernel releases.
> +
> +	  https://github.com/bus1/dbus-broker/wiki
> +
> +comment "dbusbroker needs systemd and a toolchain w/ threads"
> +	depends on BR2_USE_MMU
> +	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_SYSTEMD

  It's a nitpick, but: I think since dbus-broker is so tightly integrated with 
systemd, there's no point really to show the comment if systemd is not enabled.

> diff --git a/package/dbus-broker/dbus-broker.hash b/package/dbus-broker/dbus-broker.hash
> new file mode 100644
> index 0000000000..26ebab7ac1
> --- /dev/null
> +++ b/package/dbus-broker/dbus-broker.hash
> @@ -0,0 +1,3 @@
> +# Locally calculated
> +sha256  4eca425db52b7ab1027153e93fea9b3f11759db9e93ffbf88759b73ddfb8026a  dbus-broker-29.tar.xz
> +sha256  3cda3630283eda0eab825abe5ac84d191248c6b3fe1c232a118124959b96c6a4  LICENSE
> diff --git a/package/dbus-broker/dbus-broker.mk b/package/dbus-broker/dbus-broker.mk
> new file mode 100644
> index 0000000000..547b79eb84
> --- /dev/null
> +++ b/package/dbus-broker/dbus-broker.mk
> @@ -0,0 +1,71 @@
> +################################################################################
> +#
> +# dbus-broker
> +#
> +################################################################################
> +
> +DBUS_BROKER_VERSION = 29

  By now we're at 31 already.

  The new version uses meson's wrapgit feature instead of submodules, but 
fortunately the release tarball still include them.

> +DBUS_BROKER_SOURCE = dbus-broker-$(DBUS_BROKER_VERSION).tar.xz
> +DBUS_BROKER_SITE = https://github.com/bus1/dbus-broker/releases/download/v$(DBUS_BROKER_VERSION)
> +
> +# For the third-party code, the licensing legla-info is inconsistent between
> +# the AUTHORS and README, so keep both
> +DBUS_BROKER_LICENSE = \
> +	Apache-2.0, \
> +	Apache-2.0 and/or LGPL-2.1+ (c-dvar, c-ini, c-list, c-rbtree, c-shquote, c-stdaux, c-utf8)
> +DBUS_BROKER_LICENSE_FILES = \
> +	LICENSE \
> +	subprojects/c-dvar/AUTHORS subprojects/c-dvar/README.md \
> +	subprojects/c-ini/AUTHORS subprojects/c-ini/README.md \
> +	subprojects/c-list/AUTHORS subprojects/c-list/README.md \
> +	subprojects/c-rbtree/AUTHORS subprojects/c-rbtree/README.md \
> +	subprojects/c-shquote/AUTHORS subprojects/c-shquote/README.md \
> +	subprojects/c-stdaux/AUTHORS subprojects/c-stdaux/README.md \
> +	subprojects/c-utf8/AUTHORS subprojects/c-utf8/README.md
> +
> +DBUS_BROKER_DEPENDENCIES = expat systemd
> +DBUS_BROKER_CONF_OPTS = -Dlauncher=true
> +
> +ifeq ($(BR2_PACKAGE_AUDIT),y)
> +DBUS_BROKER_DEPENDENCIES += audit
> +DBUS_BROKER_CONF_OPTS += -Daudit=true
> +else
> +DBUS_BROKER_CONF_OPTS += -Daudit=false
> +endif
> +
> +ifeq ($(BR2_PACKAGE_LIBSELINUX),y)
> +DBUS_BROKER_DEPENDENCIES += libselinux
> +DBUS_BROKER_CONF_OPTS += -Dselinux=true
> +else
> +DBUS_BROKER_CONF_OPTS += -Dselinux=false
> +endif
> +
> +# We must be using the same user as the original dbus, so we can share
> +# the home directory and create a socket there. As a consequence, the
> +# username and groupname must be dbus:dbus, and they both need to have
> +# the same home.
> +define DBUS_BROKER_USERS
> +	dbus -1 dbus -1 * /run/dbus - dbus DBus messagebus user
> +endef
> +
> +# Only install units for system bus daemon socket if original dbus is not present
> +# Only install config and service files if original dbus is not present
> +#
> +# Note: BR2_COREUTILS_HOST_DEPENDENCY to be able to use ln --relative
> +ifeq ($(BR2_PACKAGE_DBUS),)
> +DBUS_BROKER_DEPENDENCIES += $(BR2_COREUTILS_HOST_DEPENDENCY)
> +
> +define DBUS_BROKER_INSTALL_INIT_SYSTEMD
> +	$(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/session.conf \
> +		$(TARGET_DIR)/usr/share/dbus-1/session.conf
> +	$(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/system.conf \
> +		$(TARGET_DIR)/usr/share/dbus-1/system.conf
> +	$(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/dbus.socket \
> +		$(TARGET_DIR)/usr/lib/systemd/system/dbus.socket

  I'm surprised that these files either isn't needed for original dbus, or that 
it's included in original dbus but not in dbus-broker...

> +	$(HOST_MAKE_ENV) ln -sf --relative \
> +		$(TARGET_DIR)/usr/lib/systemd/system/dbus.socket \
> +		$(TARGET_DIR)/usr/lib/systemd/system/sockets.target.wants/dbus.socket

  Is it really useful too include the coreutils dependency and HOST_MAKE_ENV, 
just to avoid having to put

	ln -sf ../dbus-socket \
		$(TARGET_DIR)/usr/lib/systemd/system/sockets.target.wants/dbus.socket


  I'm going to work more on and hopefully merge this series later today. I have 
some local changes already (spelling mistakes), so please don't resend just yet.

  Regards,
  Arnout


> +endef
> +endif # !BR2_PACKAGE_DBUS
> +
> +$(eval $(meson-package))

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

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

[Norbert Lange]

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.

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

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.

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
ExecStart=!/usr/bin/dbus-broker-launch --scope system --audit
ExecReload=!/usr/bin/busctl call org.freedesktop.DBus
/org/freedesktop/DBus org.freedesktop.DBus ReloadConfig


> > Finally, the licensing terms are pretty trivial for dbus-broker itself,
> > but it makes use of third-party code that it inherits as git submodules
> > (that are bundled in the release archive).
>
>   Ugh, bundling...
>
> > Thus the licensing is a bit
> > convoluted... The third-party codes claim to be licensed as "Apache-2.0
> > and LGP-2.1+" in their AUTHORS files, but at the same time claim
> > "**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
> > individual source files (that are used) do not seem to have any
> > licensing header to clarify the situation. So we represent the situation
> > with "Apache-2.0 and/or LGPL-2.1+".
>
>   That's rather f**d than convoluted :-)
>
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > [yann.morin.1998@free.fr:
> >    - don't select systemd; depend on it instead
> >    - only install config files and systemd units without original dbus
> >    - install a user to run the message bus as
> >    - fix licensing info
> >    - entirely reword and extend the commit log
> >    - add myself to DEVELOPERS as well
> > ]
> > Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
>
> [snip]
> > diff --git a/package/dbus-broker/Config.in b/package/dbus-broker/Config.in
> > new file mode 100644
> > index 0000000000..c7206232da
> > --- /dev/null
> > +++ b/package/dbus-broker/Config.in
> > @@ -0,0 +1,23 @@
> > +config BR2_PACKAGE_DBUS_BROKER
> > +     bool "dbus-broker"
> > +     depends on BR2_USE_MMU
> > +     depends on BR2_TOOLCHAIN_HAS_THREADS
> > +     depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_17
> > +     depends on BR2_PACKAGE_SYSTEMD
> > +     select BR2_PACKAGE_EXPAT
> > +     help
> > +       Linux D-Bus Message Broker.
> > +
> > +       The dbus-broker project is an implementation of a message bus
> > +       as defined by the D-Bus specification. Its aim is to provide
> > +       high performance and reliability, while keeping compatibility
> > +       to the D-Bus reference implementation.
> > +
> > +       It is exclusively written for Linux systems, and makes use of
> > +       many modern features provided by recent linux kernel releases.
> > +
> > +       https://github.com/bus1/dbus-broker/wiki
> > +
> > +comment "dbusbroker needs systemd and a toolchain w/ threads"
> > +     depends on BR2_USE_MMU
> > +     depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_SYSTEMD
>
>   It's a nitpick, but: I think since dbus-broker is so tightly integrated with
> systemd, there's no point really to show the comment if systemd is not enabled.
>
> > diff --git a/package/dbus-broker/dbus-broker.hash b/package/dbus-broker/dbus-broker.hash
> > new file mode 100644
> > index 0000000000..26ebab7ac1
> > --- /dev/null
> > +++ b/package/dbus-broker/dbus-broker.hash
> > @@ -0,0 +1,3 @@
> > +# Locally calculated
> > +sha256  4eca425db52b7ab1027153e93fea9b3f11759db9e93ffbf88759b73ddfb8026a  dbus-broker-29.tar.xz
> > +sha256  3cda3630283eda0eab825abe5ac84d191248c6b3fe1c232a118124959b96c6a4  LICENSE
> > diff --git a/package/dbus-broker/dbus-broker.mk b/package/dbus-broker/dbus-broker.mk
> > new file mode 100644
> > index 0000000000..547b79eb84
> > --- /dev/null
> > +++ b/package/dbus-broker/dbus-broker.mk
> > @@ -0,0 +1,71 @@
> > +################################################################################
> > +#
> > +# dbus-broker
> > +#
> > +################################################################################
> > +
> > +DBUS_BROKER_VERSION = 29
>
>   By now we're at 31 already.
>
>   The new version uses meson's wrapgit feature instead of submodules, but
> fortunately the release tarball still include them.
>
> > +DBUS_BROKER_SOURCE = dbus-broker-$(DBUS_BROKER_VERSION).tar.xz
> > +DBUS_BROKER_SITE = https://github.com/bus1/dbus-broker/releases/download/v$(DBUS_BROKER_VERSION)
> > +
> > +# For the third-party code, the licensing legla-info is inconsistent between
> > +# the AUTHORS and README, so keep both
> > +DBUS_BROKER_LICENSE = \
> > +     Apache-2.0, \
> > +     Apache-2.0 and/or LGPL-2.1+ (c-dvar, c-ini, c-list, c-rbtree, c-shquote, c-stdaux, c-utf8)
> > +DBUS_BROKER_LICENSE_FILES = \
> > +     LICENSE \
> > +     subprojects/c-dvar/AUTHORS subprojects/c-dvar/README.md \
> > +     subprojects/c-ini/AUTHORS subprojects/c-ini/README.md \
> > +     subprojects/c-list/AUTHORS subprojects/c-list/README.md \
> > +     subprojects/c-rbtree/AUTHORS subprojects/c-rbtree/README.md \
> > +     subprojects/c-shquote/AUTHORS subprojects/c-shquote/README.md \
> > +     subprojects/c-stdaux/AUTHORS subprojects/c-stdaux/README.md \
> > +     subprojects/c-utf8/AUTHORS subprojects/c-utf8/README.md
> > +
> > +DBUS_BROKER_DEPENDENCIES = expat systemd
> > +DBUS_BROKER_CONF_OPTS = -Dlauncher=true
> > +
> > +ifeq ($(BR2_PACKAGE_AUDIT),y)
> > +DBUS_BROKER_DEPENDENCIES += audit
> > +DBUS_BROKER_CONF_OPTS += -Daudit=true
> > +else
> > +DBUS_BROKER_CONF_OPTS += -Daudit=false
> > +endif
> > +
> > +ifeq ($(BR2_PACKAGE_LIBSELINUX),y)
> > +DBUS_BROKER_DEPENDENCIES += libselinux
> > +DBUS_BROKER_CONF_OPTS += -Dselinux=true
> > +else
> > +DBUS_BROKER_CONF_OPTS += -Dselinux=false
> > +endif
> > +
> > +# We must be using the same user as the original dbus, so we can share
> > +# the home directory and create a socket there. As a consequence, the
> > +# username and groupname must be dbus:dbus, and they both need to have
> > +# the same home.
> > +define DBUS_BROKER_USERS
> > +     dbus -1 dbus -1 * /run/dbus - dbus DBus messagebus user
> > +endef
> > +
> > +# Only install units for system bus daemon socket if original dbus is not present
> > +# Only install config and service files if original dbus is not present
> > +#
> > +# Note: BR2_COREUTILS_HOST_DEPENDENCY to be able to use ln --relative
> > +ifeq ($(BR2_PACKAGE_DBUS),)
> > +DBUS_BROKER_DEPENDENCIES += $(BR2_COREUTILS_HOST_DEPENDENCY)
> > +
> > +define DBUS_BROKER_INSTALL_INIT_SYSTEMD
> > +     $(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/session.conf \
> > +             $(TARGET_DIR)/usr/share/dbus-1/session.conf
> > +     $(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/system.conf \
> > +             $(TARGET_DIR)/usr/share/dbus-1/system.conf
> > +     $(INSTALL) -D -m 0644 $(DBUS_BROKER_PKGDIR)/dbus.socket \
> > +             $(TARGET_DIR)/usr/lib/systemd/system/dbus.socket
>
>   I'm surprised that these files either isn't needed for original dbus, or that
> it's included in original dbus but not in dbus-broker...

Not sure I understand what you are saying. They are needed for the
original dbus,
and not included in dbus-broker as the IPC daemon could
(theoretically) run without.
See [2].

>
> > +     $(HOST_MAKE_ENV) ln -sf --relative \
> > +             $(TARGET_DIR)/usr/lib/systemd/system/dbus.socket \
> > +             $(TARGET_DIR)/usr/lib/systemd/system/sockets.target.wants/dbus.socket
>
>   Is it really useful too include the coreutils dependency and HOST_MAKE_ENV,
> just to avoid having to put
>
>         ln -sf ../dbus-socket \
>                 $(TARGET_DIR)/usr/lib/systemd/system/sockets.target.wants/dbus.socket

Yann is very determined about that [3].

>   I'm going to work more on and hopefully merge this series later today. I have
> some local changes already (spelling mistakes), so please don't resend just yet.
>
>   Regards,
>   Arnout
>
>
> > +endef
> > +endif # !BR2_PACKAGE_DBUS
> > +
> > +$(eval $(meson-package))
>
> [snip]

Norbert

[1] - https://packages.debian.org/source/sid/dbus.
[2] - https://github.com/bus1/dbus-broker/issues/262
[3] - http://lists.busybox.net/pipermail/buildroot/2020-June/587178.html
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Arnout Vandecappelle]

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.


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

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


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

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

[Norbert Lange]

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

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

[Arnout Vandecappelle]

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

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

[Norbert Lange]

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