3 ms·

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 progra

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.

kingosticks 5y ago
> 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, Do you have any more details about this? Doesn't dbus complain about that? Is this something more than changing the socket file permissions. Last time I tried to access the user session bus from something outside the session I ran into this kludge https://serverfault.com/questions/892465/starting-systemd-services-sharing-a-session-d-bus-on-headless-system https://serverfault.com/questions/892465/starting-systemd-se... I'm happy with the socket solution because it's got the security level I want (anyone on the local machine with local access to the socket file is fine) and I can really, really easily build whatever I want on top of it or plug it into whatever library because it's a simple socket. I want to use dbus, it seems the Right Way but it always seems to throw up road blocks.
- taway098123 5y ago
  Dbus won't allow it because you have to switch to that user before it lets you connect. You would have to have whatever is doing the access running as root and then change its user. There's not really any magic here, it's just a socket with access controls on it, the same thing you would be building anyway.

kingosticks 5y ago

> 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, Do you have any more details about this? Doesn't dbus complain about that? Is this something more than changing the socket file permissions. Last time I tried to access the user session bus from something outside the session I ran into this kludge https://serverfault.com/questions/892465/starting-systemd-services-sharing-a-session-d-bus-on-headless-system https://serverfault.com/questions/892465/starting-systemd-se... I'm happy with the socket solution because it's got the security level I want (anyone on the local machine with local access to the socket file is fine) and I can really, really easily build whatever I want on top of it or plug it into whatever library because it's a simple socket. I want to use dbus, it seems the Right Way but it always seems to throw up road blocks.

taway098123 5y ago
Dbus won't allow it because you have to switch to that user before it lets you connect. You would have to have whatever is doing the access running as root and then change its user. There's not really any magic here, it's just a socket with access controls on it, the same thing you would be building anyway.