[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-dbus
Subject: Re: Using D-Bus for private IPC
From: Link Dupont <link () sub-pop ! net>
Date: 2022-09-26 18:34:00
Message-ID: O8YTIR.GQRZ08Z9M3832 () sub-pop ! net
[Download RAW message or body]
On Mon, Sep 26 2022 at 10:39:07 AM -0700, Thiago Macieira
<thiago@kde.org> wrote:
> On Monday, 26 September 2022 08:39:12 PDT Link Dupont wrote:
>> Hello,
>>
>> I'm designing a service that exists as multiple separate processes.
>> These processes communicate over IPC. I'm considering using D-Bus as
>> that IPC, but I have a couple questions. I would like to isolate the
>> processes onto a private bus. Is that a good idea, or does that go
>> against the design principles of using a message bus for IPC?
>
> Hello Link
>
> It's not usual to do this, but not unheard of either. I believe the
> AT-SPI
> accessibility protocol uses a private bus.
>
> Note that if you only ever have 2 applications, you can avoid the bus
> completely and use D-Bus in peer-to-peer mode.
It's a one-to-many model, so I'm not sure peer-to-peer would work. One
process is the server, and there are many processes that are clients.
>> Is there
>> some other recommended way of isolating services so that they are
>> not
>> easily interacted with except by authorized processes? Is there a
>> better way to create a private bus session from within a systemd
>> unit,
>> or is 'ExecStart=dbus-run-session /usr/bin/myprog' the recommended
>> way
>> to start up a private bus?
>
> I can't comment on systemd units.
>
> The thing about "authorised" usually implies some type of security
> and that
> can only be achieved with the system bus. You can poke sufficient
> holes so only
> authorised applications can communicate with each other there. A
> private bus
> works too, but it'll run in session mode allowing anyone who has the
> correct
> UID to connect. So you secure this by simply having a socket address
> that
> isn't known outside your small circle of applications, and it becomes
> your
> problem to ensure it doesn't accidentally "leak" such as by storing
> it in a
> world-readable file in /tmp.
I've been reading about the <policy> rules, and it seems like I might
be able to run it on the system bus, with certain rules in place to
permit messages only between the two destinations. Is something like
this a valid rule?
<allow send_destination_prefix="org.foo.Agent"
receive_destination="org.foo.Owner"/>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
[Attachment #3 (text/html)]
<div id="geary-body" dir="auto"><div><br></div></div><div id="geary-quote" \
dir="auto"><br>On Mon, Sep 26 2022 at 10:39:07 AM -0700, Thiago Macieira \
<thiago@kde.org> wrote:<br><blockquote type="cite"><div class="plaintext" \
style="white-space: break-spaces;">On Monday, 26 September 2022 08:39:12 PDT Link \
Dupont wrote: <blockquote> Hello,
I'm designing a service that exists as multiple separate processes.
These processes communicate over IPC. I'm considering using D-Bus as
that IPC, but I have a couple questions. I would like to isolate the
processes onto a private bus. Is that a good idea, or does that go
against the design principles of using a message bus for IPC?
</blockquote>
Hello Link
It's not usual to do this, but not unheard of either. I believe the AT-SPI
accessibility protocol uses a private bus.
Note that if you only ever have 2 applications, you can avoid the bus
completely and use D-Bus in peer-to-peer mode.<br></div></blockquote><span \
style="white-space: break-spaces;"><div><span style="white-space: \
break-spaces;"><br></span></div><div><span style="white-space: break-spaces;">It's a \
one-to-many model, so I'm not sure peer-to-peer would work. One process is the \
server, and there are many processes that are \
clients.</span></div><br></span><blockquote type="cite"><div class="plaintext" \
style="white-space: break-spaces;"><blockquote> Is there some other recommended way \
of isolating services so that they are not easily interacted with except by \
authorized processes? Is there a better way to create a private bus session from \
within a systemd unit, or is 'ExecStart=dbus-run-session /usr/bin/myprog' the \
recommended way to start up a private bus?
</blockquote>
I can't comment on systemd units.
The thing about "authorised" usually implies some type of security and that
can only be achieved with the system bus. You can poke sufficient holes so only
authorised applications can communicate with each other there. A private bus
works too, but it'll run in session mode allowing anyone who has the correct
UID to connect. So you secure this by simply having a socket address that
isn't known outside your small circle of applications, and it becomes your
problem to ensure it doesn't accidentally "leak" such as by storing it in a
world-readable file in /tmp.</div></blockquote><span style="white-space: \
break-spaces;"><div><span style="white-space: \
break-spaces;"><br></span></div><div><span style="white-space: break-spaces;">I've \
been reading about the <policy> rules, and it seems like I might be able to run \
it on the system bus, with certain rules in place to permit messages only between the \
two destinations. Is something like this a valid rule?</span></div><div><span \
style="white-space: break-spaces;"><br></span></div><div><span style="white-space: \
break-spaces;"><allow send_destination_prefix="org.foo.Agent" \
receive_destination="org.foo.Owner"/></span></div><br></span><blockquote \
type="cite"><div class="plaintext" style="white-space: break-spaces;"><div>-- \
</div>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software \
Architect - Intel DCAI Cloud Engineering
</div></blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic