A way to get sender's PID ?

[Thorsten Koch]

Thanks again for the answer.

> Since the D-Bus server daemon works using Unix sockets, it's possible to
> use the SO_PEERCRED getsockopt() call to retrieve the peer's identity,
> including UID and PID.
> But note that this only works on Unix sockets. If your D-Bus daemon is
> offering access via any other protocol (like TCP/IP), you may get an
> unreliable behaviour, since the daemon cannot determine the PID of the
> caller.
Does that mean that the SO_PEERCRED getsockopt() call cannot be used for 
Linux !? And is it only the PID or is it possible to get also the TID because 
someone could work with threads.

> >To your question:
> >What I wanna do is to map the caller to the callee - means their PIDs in
> > order to establish a calltree.
>
> Well, the callee is you. Why do you want to have such a calltree?
>
> Or is this an external process that is eavesdropping and trying to provide
> timing & profiling for D-Bus calls?

With callee I mean the server-service which could be a process or even a 
thread which means a LW process. Therefore a TID would be nice.
What I need is the relation between the calling client who calls a 
service "org.company.xyz" and the callee who runs the service on a server. 
This communication goes through the DBUS-DAEMON and therefore I guess it is a 
good position to log all the calls from a client to a service.

Maybe there are two options:
1. We add our functionality directly into the dbus-daemon as let's say a 
plugin.
OR
2. We use like dbus-monitor a separate program to eavesdrop the dbus but that 
could be difficult once encryption could hide the necessary informations.

By the way we are doing that for QoS purposes.

What do you think? Is there a way to do that directly (e.g. with the 
SO_PEERCRED getsockopt()) without the need for sending a PID / TID in a 
separate message or in an additional field of a dbus-registration call etc ??
You know transparency is important for those who wants to develop services for 
such a QoS-Manager. If they just could use the DBUS-API and we would do the 
rest in the manager that would be great. But my first guess was that we have 
to send additional informations within some messages.

Thanks a lot 
  Thorsten