On Wed, Sep 23, 2026 at 6:29 AM David Bidner <[email protected]> wrote: > Thanks for the earlier reply. Following your suggestion, the rework uses the > Linux socket option instead of the fstat approach: > > getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &ucred, &len) > struct ucred { pid_t pid; uid_t uid; gid_t gid; } > > pflocal records the peer's uid/gid and returns them from S_socket_getopt; > io_stat/fstat are unchanged. The series also sets the credentials on the > connecting socket and on both socketpair() ends, and declares SO_PEERCRED / > struct ucred (under __USE_GNU, like Linux) in a separate glibc header patch.
Hello, I earlier described some issues with this approach here: https://lists.gnu.org/archive/html/bug-hurd/2023-02/msg00054.html ("On SO_PEERCRED & SCM_CREDS" and the follow-up message) Specifically: we should generally avoid transmitting things like UIDs, GIDs, and PIDs as numeric values in RPCs. That's because that doesn't work nicely across "namespace" boundaries; of course the Hurd doesn't have PID/UID namespaces in the Linux sense, but there are things such as subhurds and fakeauth. What we should always try to do is use capability mechanisms to reliably identify one party to another, and then derive numeric values (UIDs, PIDs) in a namespace that make sense for the relevant process. For UIDs, it basically means SO_PEERCRED/SCM_CREDS-like behavior should be implemented with the peer authenticating itself to us using the Hurd's auth protocol through an auth server that we trust, and that returns numeric UIDs/GIDs in a namespace that we recognize. I would be happy to expand further if that doesn't make too much sense. Other existing violations of this principle are term_open_ctty and io_{get,mod}_owner, which both transfer numeric PIDs over RPCs -- while, again, numeric PIDs might mean different things to the server and the client. Sergey
