CREDENTIALS

The high-level meaning of this access control type is that only the same user (e.g. same numeric Unix uid) is allowed to interact with the tube.

Exactly how this is achieved varies by channel type. For StreamTube channels, this access control type may only be used on UNIX sockets. The connecting process must send a byte when it first connects, which is not considered to be part of the data stream. If the operating system uses sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over sockets, the connecting process must do so if possible; if not, it must still send the byte, without any attached credentials. (This mechanism is very similar to the first byte of a D-Bus connection, except that in D-Bus the byte is always zero, whereas in Tubes it can be nonzero.) For DBusTube channels, this access control type may be used on any type of socket, and there is no extra byte added by Telepathy at the beginning of the stream: all bytes in the stream are part of the D-Bus tube connection. The connecting process should prove its identity via any of the SASL authentication mechanisms usually used for D-Bus (in typical D-Bus implementations this involves either sending and receiving credentials as above, or demonstrating the ability to write to a file in the user's home directory). In either case, the listening process will disconnect the connection unless it can determine by OS-specific means that the connecting process has the same user ID as the listening process. In either tube type, the associated variant must be ignored.