Using D-Bus for private IPC

Thiago Macieira thiago at kde.org
Mon Sep 26 17:39:07 UTC 2022


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.

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

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering





More information about the dbus mailing list