[taway098123]

Yes it can, why wouldn't it? You can make a program that connects to more than one bus. Though that would probably be crossing a security boundary. The simple way to make multi-user services is to just deploy them on the system bus and be done with it.

[kingosticks]

I'm not sure I'm supposed to engage with throwaway accounts but here goes.

Why can't a program on the user bus send a message to a program on the system bus and vice versa? Because dbus messages cannot transit between buses. That is why.

The workaround of straddling both buses is something I recently had a good look for. To see if that was a reasonable thing to do. I couldn't find a single example of a program doing this. I think that's because it's a security bodge trying to evade the intentional isolation built into dbus. Although if I'm honest I think it's an OK workaround as you can restrict the system bus access.

The problem I keep genuinely running into is the existing programs I want to talk to (and don't control) only sit on the user bus, very very rarely the system bus because they are gui programs tied into the user session. So my program is then forced to run as the same user. And even that's not enough because they need to run under the same user session, not just the same user. This restriction is a deal-breaker for my system service-type programs and is totally avoidable when using other communication methods (which those existing programs also provide, presumably because they realise dbus is often totally unusable).

The simple way is to use a Unix socket and that's why people continue to "litter" the filesystem with them. You can even get a bit of auth with them.

[taway098123]

I'm sorry about the throwaway, it's a long story.

You're crossing a security boundary trying to access other users' GUI programs. The session bus is for programs that are private to the user's session. Accessing that is mostly equivalent to logging in as that user, you're not supposed to take control of all their programs as another user.

I don't really understand your solution, the problem doesn't go away when you use a Unix socket. You're still crossing a security boundary and now you have to build in those access controls into your program. If you don't really care about the security aspect it would be just as easy to tell the user to grant you access to the dbus socket for their session bus, or run another dbus instance under a different user and control access to that socket. You can publish the same interface on multiple buses at once, and build in your own access controls too.

[Spivak]

Yep! dbus has really really good auth support so that users can talk to the system bus without needing to be otherwise privileged. The nicest is implicit auth where the dbus can just ask the kernel for the clients uid and authorize based on that. Very easy to implement and manage.