<div dir="ltr"><div>Thanks for the detailed explanation!</div><div> </div><div> Calling g_dbus_method_invocation_get_sender() and then GetConnectionUnixProcessID work and I can get the peer's PID now.</div><div> </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 23, 2022 at 2:15 PM Simon McVittie <<a href="mailto:smcv@collabora.com">smcv@collabora.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 22 May 2022 at 11:40:35 +0300, Amira S wrote: > Any idea if/how it is possible to get the peer's PID connecting to a SYSTEM > bus? g_dbus_method_invocation_get_sender() will tell you the peer's unique connection name, and then you can look that up with GetConnectionUnixProcessID or GetConnectionCredentials to get the process ID (for example you might use g_dbus_connection_call() to call one of those methods). polkit <<a href="https://gitlab.freedesktop.org/polkit/polkit/" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/polkit/polkit/</a>> is an example of a system service that does this. > According to the documentation, it is possible to obtain a GCredentials from > the connection by calling [1]g_dbus_connection_get_peer_credentials, (and from > there I can get a unix ucred that has the pid), but I always get a NULL > credentials. > The documentation for this function says: > "Gets the credentials of the authenticated peer. This will always return [2] > NULL unless connection acted as a server You are not the server, so the documentation correctly says that it will return NULL for you. Normal use of D-Bus on the system or session bus is in a "star" topology, where the message bus (dbus-daemon or dbus-broker) is the middle of the star, and all clients and services are at the points of the star: app 2 } | } (AF_UNIX socket clients) app 1 | app 3 } \ | / \ | / message bus (AF_UNIX socket server) / | \ / | \ service A | service C } | } (also AF_UNIX socket clients) service B } We often talk about services as though they were something special, but there is not really any fundamental difference between services and other applications: they're all clients of the message bus. The role of the message bus is often called a "broker" in other IPC protocols. Depending who you ask, a service is either a D-Bus peer that owns a well-known name like "com.microsoft.mscrypt", or a D-Bus peer that was started automatically by the message bus to provide the implementation of a well-known name, or a D-Bus peer that provides methods to be called by other peers. In practice, most peers that are referred to as "services" do all of these things. > I also tried getting the PID by calling programmatically the following command: > > dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/ > DBus org.freedesktop.DBus.GetConnectionUnixProcessID > ‘string:com.microsoft.mscrypt’ > > But I always receive the server's PID, and not the client's. No, you receive the process ID of the service that owns the name "com.microsoft.mscrypt". Don't confuse the service (a high-level concept) with the AF_UNIX server (a lower-level concept). If you are using GDBus, you should call D-Bus methods with something like g_dbus_connection_call() or g_dbus_connection_call_sync(), g_dbus_proxy_call() or client code generated by gdbus-codegen, instead of running dbus-send as a subprocess (which does the same thing, but less efficiently). smcv </blockquote></div>