From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5D807C04A68 for ; Wed, 27 Jul 2022 19:24:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E9B648291C; Wed, 27 Jul 2022 19:24:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E9B648291C X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o37uCt1pp73J; Wed, 27 Jul 2022 19:24:43 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp1.osuosl.org (Postfix) with ESMTP id 3CC8482907; Wed, 27 Jul 2022 19:24:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3CC8482907 Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 9BF981BF3C6 for ; Wed, 27 Jul 2022 19:24:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 8429260E41 for ; Wed, 27 Jul 2022 19:24:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8429260E41 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_vEs3dKG-wm for ; Wed, 27 Jul 2022 19:24:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F0FC560D9C Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) by smtp3.osuosl.org (Postfix) with ESMTPS id F0FC560D9C for ; Wed, 27 Jul 2022 19:24:38 +0000 (UTC) Received: by mail-vs1-xe2e.google.com with SMTP id b67so9748901vsc.1 for ; Wed, 27 Jul 2022 12:24:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t/Ge/8ZmnYcAHcC9vQqmk7ntT0EBAxZcExW59G2I3eI=; b=tAOD34W8hzm0hFIoPtTsW8AoCU7lWrQr0zpPPDBIZeYerStU6hgmPRXdQNjdVkHMgv aE0wMa43hWjMZ+Nwjia8yZDzIfObXLW7CqMIMmh5wXFoWAbLw9oUA+CclxeMz/HQ8gQ0 IZJ45F7LppfOoar2Qq4hy+QBVDzaORc86U9ZTv4+ybOC3O0boj/smQ1R3h+T1+2d44dL lWGpQKoy4VDzOD5sfda2ctW+9c7IJYTxvDDcsyNxkV1KCl63SuBfMEkCnw1AasN5B3dQ izXpSF04yaLXZRISM8ZXRa7flbTg34pgYkPbAKQxllUsrIAPlQOd/o72wJ4RnafC6gZy qiaQ== X-Gm-Message-State: AJIora/zq6AMKZ6CTqvGwbUgi9tC6TKzlmw8oF9P5ohnZoSuDHRWFU9i TYp1CNxf9I2Tkj+1ehezEWU3UN8TIZ3D+Wzwj5iCbk9wSqA= X-Google-Smtp-Source: AGRyM1uMO5X7IMomaXKnkHzJRBkzrJsvtUm6vhjEoIKNE1Y7oOMaCIRm8XIRN3aF7Q71thWavmOxy5BIbhyBwe2vhZw= X-Received: by 2002:a67:e101:0:b0:358:4660:345c with SMTP id d1-20020a67e101000000b003584660345cmr7878805vsl.27.1658949877722; Wed, 27 Jul 2022 12:24:37 -0700 (PDT) MIME-Version: 1.0 References: <20220109221650.777610-1-nolange79@gmail.com> <2288ff34-d140-a1a0-3f8e-86baf04f4dee@mind.be> <28488fd2-ab02-43c7-25da-cdcb3f37d83a@mind.be> <289f02de-d0f2-347f-28be-0cfe52478990@mind.be> In-Reply-To: <289f02de-d0f2-347f-28be-0cfe52478990@mind.be> From: Norbert Lange Date: Wed, 27 Jul 2022 21:24:26 +0200 Message-ID: To: Arnout Vandecappelle X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t/Ge/8ZmnYcAHcC9vQqmk7ntT0EBAxZcExW59G2I3eI=; b=IP2LvYHckm/By/OGzSgHLRp/9m4gWwPTIoTD13ajPwCtTq3tfs2VfGtYnAHL0ynVZa 7kj3JyIUpIOq6NMZTaiosi4hGir1aeiaLpPCBXTZP9amUnjXzl8sg0PvQ1CvZ22rJzsn hOP/yEgL5QBAnSR2c+o5TmKEHA5xqOV7KqOMCgQp0UnLpNTHKERuzwGhwmGPecVY3SXP 3I/1o9/dQxLo8G4SRYBtrzvEhPvp7V5qTeuUY77BWsZFfCCtAkO114SZAHUlpi7E1t9n 19TbHHKCbWTuaM+BoOcLAh0szPUEBu81zIYwdozZf6BPH5FLkX0k4g4YBsZCUfoceDJ3 CzHg== X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=IP2LvYHc Subject: Re: [Buildroot] [PATCH v6 1/4] package/dbus-broker: new package X-BeenThere: buildroot@buildroot.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion and development of buildroot List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eric Le Bihan , "Yann E . MORIN" , buildroot Content-Type: multipart/mixed; boundary="===============4876477243690057111==" Errors-To: buildroot-bounces@buildroot.org Sender: "buildroot" --===============4876477243690057111== Content-Type: multipart/alternative; boundary="00000000000029722d05e4ce5ec1" --00000000000029722d05e4ce5ec1 Content-Type: text/plain; charset="UTF-8" Arnout Vandecappelle schrieb am Mi., 27. Juli 2022, 21:09: > > > On 27/07/2022 19:31, Norbert Lange wrote: > > > > > > Arnout Vandecappelle > 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 > > > >: > [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 and 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 > > > --00000000000029722d05e4ce5ec1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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>&= gt; schrieb am Mi.,
> 27. Juli 2022, 19:05:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On 27/07/2022 15:47, Norbert Lange wrote:
>=C2=A0 =C2=A0 =C2=A0 > Am Mi., 27. Juli 2022 um 13:08 Uhr schrieb Ar= nout Vandecappelle
>=C2=A0 =C2=A0 =C2=A0 > <arnout@mind.be <mailto:arnout@mind.be= >>:
[snip]
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 So to me the proper approach= seems to change dbus itself so the daemon is
>=C2=A0 =C2=A0 =C2=A0 >> optional, i.e. only libdbus is installed = if the daemon is not enabled,
>=C2=A0 =C2=A0 =C2=A0similar
>=C2=A0 =C2=A0 =C2=A0 >> to e.g. libcurl. BR2_PACKAGE_DBUS_DAEMON = should default to y because
>=C2=A0 =C2=A0 =C2=A0that's what
>=C2=A0 =C2=A0 =C2=A0 >> most people want. We'd have to go thr= ough existing packages to check if they
>=C2=A0 =C2=A0 =C2=A0 >> depend on libdbus or on the daemon - most= ly it will be the first. If
>=C2=A0 =C2=A0 =C2=A0there is a
>=C2=A0 =C2=A0 =C2=A0 >> package that really needs the daemon (I d= on't actually think so), then
>=C2=A0 =C2=A0 =C2=A0we might
>=C2=A0 =C2=A0 =C2=A0 >> need to introduce a virtual package for t= he daemon. Regardless, dbus-broker
>=C2=A0 =C2=A0 =C2=A0 >> should depend on !BR2_PACKAGE_DBUS_DAEMON= .
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Looking more detailed at it, this seems too= complicated. dbus doesn't
>=C2=A0 =C2=A0 =C2=A0offer a
>=C2=A0 =C2=A0 =C2=A0way to install only the library. Also in terms of r= ootfs size, the only
>=C2=A0 =C2=A0 =C2=A0difference is the dbus-daemon and dbus-launch binar= ies, plus a few config
>=C2=A0 =C2=A0 =C2=A0files.
>=C2=A0 =C2=A0 =C2=A0Not really sufficient to make it worth it.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 What I will do, I think, is to include logi= c in dbus to remove the
>=C2=A0 =C2=A0 =C2=A0activation
>=C2=A0 =C2=A0 =C2=A0units (both the service and the socket) when dbus-b= roker is enabled. It is
>=C2=A0 =C2=A0 =C2=A0slightly messy because dbus.mk <http://dbus.= mk> and dbus-broker.mk
>=C2=A0 =C2=A0 =C2=A0<http://dbus-broker.mk> become fai= rly tightly woven
>=C2=A0 =C2=A0 =C2=A0together, but I think it's worth it from a usab= ility perspective.
>
>
> Sounds messy too,

=C2=A0 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 pret= ty
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).

=C2=A0 That is a good idea. However, it only works for the two dbus configu= ration
files, not for the systemd units, so it only solves half of the mess. And t= he
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
>
>
>=C2=A0 =C2=A0 =C2=A0 > Debian does something similar, including spli= tting of the xml config files
>=C2=A0 =C2=A0 =C2=A0 > and actual daemons into their own packages. >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > see [1].
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>> Note about the user: the path to the = system bus socket is a so-called
>=C2=A0 =C2=A0 =C2=A0 >>> "well-known location": it i= s expected to be there, by spec. Moving it
>=C2=A0 =C2=A0 =C2=A0 >>> elsewhere is going to break existing = programs. So, the user running the
>=C2=A0 =C2=A0 =C2=A0 >>> system bus daemon must be able to cre= ate that socket.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> As we may have two packages providing= a system bus daemon, they have to
>=C2=A0 =C2=A0 =C2=A0 >>> be both able to create the socket, an= d thus must both be able to write
>=C2=A0 =C2=A0 =C2=A0 >>> in the directory containing the socke= t. And since they can be switched
>=C2=A0 =C2=A0 =C2=A0 >>> at runtime, they must be running as t= he same user.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> We can't just reference the origi= nal dbus user, so we duplicate the
>=C2=A0 =C2=A0 =C2=A0 >>> entry. What is important, is that the= user be named 'dbus', as that's
>=C2=A0 =C2=A0 =C2=A0 >>> what we use in both cases.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 If it's a virtual packag= e, then the user could be created by the virtual
>=C2=A0 =C2=A0 =C2=A0 >> package itself.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 It won't be a virtual package, so no lo= nger relevant.
>
>
>=C2=A0 =C2=A0 =C2=A0 > with systemd you probably dont even need a re= al user for the isolation
>=C2=A0 =C2=A0 =C2=A0 > benefits.
>=C2=A0 =C2=A0 =C2=A0 > So maybe this would just be necessary if dbus= utilities are used,
>=C2=A0 =C2=A0 =C2=A0 > you can also just let systemd create that use= r dynamically:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > [Service]
>=C2=A0 =C2=A0 =C2=A0 > ...
>=C2=A0 =C2=A0 =C2=A0 > User=3Ddbus
>=C2=A0 =C2=A0 =C2=A0 > Group=3Ddbus > DynamicUser=3Dtrue
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If we do this both in the dbus and the dbus= -broker units, then indeed we can
>=C2=A0 =C2=A0 =C2=A0remove 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)

=C2=A0 Well, the service file still calls dbus-broker-launch, which I guess= does
setuid because the upstream service file doesn't have any User=3D or Gr= oup=3D

I meant Dbus-launch, dbus-broker-launch *do= es not use setuid* which depends on filesystem/inode permissions and uid.
If you prefix a ! In the service file dbus-broker-lau= nch will be run as root, and since this is the only way the executable is u= sed (unlike dbus) the dynamic user uid is enough.
Hence dbus-broker-launch works with random/dynami= c uids, while dbus-launch needs a stable one.


=C2=A0 I think we'll just stick to what we have now, and keep the upstr= eam service
file rather than hacking our own...

=C2=A0 Regards,
=C2=A0 Arnout

>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If I add this just to dbus-broker, but dbus= still creates a static user, is
>=C2=A0 =C2=A0 =C2=A0this going to give a problem for systemd? I.e. does= systemd support a
>=C2=A0 =C2=A0 =C2=A0DynamicUser=3Dtrue if the user exists already stati= cally? I think so...
>
>
> Think so too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Arnout
>
>=C2=A0 =C2=A0 =C2=A0 > ExecStart=3D!/usr/bin/dbus-broker-launch --sc= ope system --audit
>=C2=A0 =C2=A0 =C2=A0 > ExecReload=3D!/usr/bin/busctl call org.freede= sktop.DBus
>=C2=A0 =C2=A0 =C2=A0 > /org/freedesktop/DBus org.freedesktop.DBus Re= loadConfig
>
>=C2=A0 =C2=A0 =C2=A0[snip]
>
>
> Norbert
>
--00000000000029722d05e4ce5ec1-- --===============4876477243690057111== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot --===============4876477243690057111==--