A way to get sender's PID ?

[Thiago Macieira]

Thorsten Koch wrote:
>> 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 !? 

Where did you get that idea from?

SO_PEERCRED is found mainly on Linux, but also on other Unix platforms.

>And is it only the PID or is it possible to get also the TID 
> because someone could work with threads.

No. A socket belongs to a process, not to a thread. Asking for TID doesn't 
make any sense at all.

Then again, all of the information (PID, UID and GID) can conceivably 
change, so they are only the snapshot of the time the socket is created. 
So why not TID...

You'll have to ask the Linux kernel hackers for that, though.

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

You can log all calls using dbus-monitor or any other eavesdropping tool.

The information it finds is the unique connection name of the source, plus 
the destination service. If you want a finer-grained solution for 
lightweight processes, you'll need to open multiple connections to the 
D-Bus server.

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

Encryption?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061115/56400e08/attachment.pgp