From: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@xxxxxxxxxxxxx> Date: Sun, 9 Mar 2025 14:28:11 +0100 > 1. Add socket cgroup id and socket's peer cgroup id in socket's fdinfo Why do you want to add yet another racy interface ? > 2. Add SO_PEERCGROUPID which allows to retrieve socket's peer cgroup id > 3. Add SO_PEERCGROUPID kselftest > > Generally speaking, this API allows race-free resolution of socket's peer cgroup id. > Currently, to do that SCM_CREDENTIALS/SCM_PIDFD -> pid -> /proc/<pid>/cgroup sequence > is used which is racy. Few more words about the race (recycling pid ?) would be appreciated. I somewhat assumed pid is not recycled until all of its pidfd are close()d, but sounds like no ? > > As we don't add any new state to the socket itself there is no potential locking issues > or performance problems. We use already existing sk->sk_cgrp_data. > > We already have analogical interfaces to retrieve this > information: > - inet_diag: INET_DIAG_CGROUP_ID > - eBPF: bpf_sk_cgroup_id > > Having getsockopt() interface makes sense for many applications, because using eBPF is > not always an option, while inet_diag has obvious complexety and performance drawbacks > if we only want to get this specific info for one specific socket. If it's limited to the connect()ed peer, I'd add UNIX_DIAG_CGROUP_ID and UNIX_DIAG_PEER_CGROUP_ID instead. Then also ss can use that easily.
