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