SO_PEERCRED vs SCM_CREDENTIALS - why are they both?

SO_PEERCRED is an easy way to get the pid / uid / gid of a connected socket on an AF_UNIX stream, SCM_CREDENTIALS is more or less the same but more complex (various helper messages). Links to an example showing both methods .

  • Why are there two ways to get more or less the same information?
  • Why is the more comfortable SO_PEERCRED not listed in the unix (7) man page?
  • What is more used in real applications?

What should i use?

+6
source share
2 answers
  • If I understand correctly, there is a subtle difference between them. SO_PEERCRED retrieves the credentials of the peer process without requiring any interaction from the peer process. In contrast, SCM_CREDENTIALS is a mechanism for sending / receiving credentials of a peer process, which are then verified by the kernel. This subtle difference can make a difference when a process runs as UID 0. SCM_CREDENTIALS allows a process running as UID 0 to declare itself less privileged (for example, UID 50), while this is not possible for SO_PEERCRED .

  • See above. I assume SCM_CREDENTIALS recommended, and SO_PEERCRED is only supported for compatibility.

  • The dbus daemon uses SO_PEERCRED and getpeereid() . I think it's best to copy their code to get credentials portable.

http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c?id=edaa6fe253782dda959d78396b43e9fd71ea77e3

+6
source

SO_PEERCRED returns peer socket credentials. SCM_CREDENTIALS allows SCM_CREDENTIALS to transfer any credentials that you have. This is especially valuable because the kernel will translate identifiers, so a task in one pid namespace can send pid for processing to another namespace and be sure that the resulting pid will refer to the same process that it was planning.

If you want to have a peer account, use SO_PEERCRED . SCM_CREDENTIAL is the credentials that the caller indicated (to which he should have privilege), not necessarily equal.

0
source

Source: https://habr.com/ru/post/912546/


All Articles