-
Simon McVittie authored
On Linux, if getsockopt SO_PEERCRED is used on a TCP socket, one might expect it to fail with an appropriate error like ENOTSUP or EPROTONOSUPPORT. However, it appears that in fact it succeeds, but yields a credentials structure with pid 0, uid -1 and gid -1. These are not real process, user and group IDs that can be allocated to a real process (pid 0 needs to be reserved to give kill(0) its documented special semantics, and similarly uid and gid -1 need to be reserved for setresuid() and setresgid()) so it is not meaningful to signal them to high-level API users. An API user with Linux-specific knowledge can still inspect these fields via g_credentials_get_native() if desired. Similarly, if SO_PASSCRED is used to receive a SCM_CREDENTIALS message on a receiving Unix socket, but the sending socket had not enabled SO_PASSCRED at the time that the message was sent, it is possible for it to succeed but yield a credentials structure with pid 0, uid /proc/sys/kernel/overflowuid and gid /proc/sys/kernel/overflowgid. Even if we were to read those pseudo-files, we cannot distinguish between the overflow IDs and a real process that legitimately has the same IDs (typically they are set to 'nobody' and 'nogroup', which can be used by a real process), so we detect this situation by noticing that pid == 0, and to save syscalls we do not read the overflow IDs from /proc at all. This results in a small API change: g_credentials_is_same_user() now returns FALSE if we compare two credentials structures that are both invalid. This seems like reasonable, conservative behaviour: if we cannot prove that they are the same user, we should assume they are not. Signed-off-by: Simon McVittie <smcv@collabora.com>
1485a97d