SO_PEERCRED is simple way to get pid/uid/gid of connected AF_UNIX stream socket, SCM_CREDENTIALS is more or less the same, but more complex (various ancillary messages). Links to example showing both ways.
What should I use?
If I understand correctly, there is a subtle difference between the two. SO_PEERCRED retrieves the credentials of the peer process, without requiring any interaction from the peer process. In contrast, SCM_CREDENTIALS is a mechanism to send / receive credentials of the peer process, which are then checked by the kernel. This subtle difference may matter when a process is running as UID 0. SCM_CREDENTIALS allows a process running as UID 0, to declare itself less privileged (e.g., UID 50), whereas this would not be possible with SO_PEERCRED.
See above. I guess using SCM_CREDENTIALS is encouraged and SO_PEERCRED is only supported for compatibility.
The dbus daemon seems to use SO_PEERCRED and getpeereid(). I think it is best to copy their code in order to portably get the credentials.
SO_PEERCRED returns the socket peer's credentials. SCM_CREDENTIALS allows you to pass any credentials which you have privilege over. This is particularly valuable because the kernel will translate the ids, so a task in one pid namespace can send a pid to process in another namespace, and be assured that the received pid will refer to the same process it intended.
If you want the peer's credential then use SO_PEERCRED. SCM_CREDENTIAL is a credential which the caller specified (which it did have to have privilege over), not necessarily the peer's.
