Good morning, I was advised to list some benefits of my proposed patch (see https://marc.info/?l=openbsd-tech&m=163257974326508&w=2) adding SO_PASSCRED to motivate its acceptance.
First, to clear up any misconceptions: this is an entirely different mechanism to SO_PEERCRED. SO_PEERCRED is for stream and sequenced-packet sockets. This however is mainly for datagram sockets. That is why it's useful. There is no way to authenticate the sender of a datagram in the Unix domain on OpenBSD right now. Well - I've seen some ugly attempts to do so anyway - like a port providing a daemon which expects anyone sending it a datagram to first make a file in their home directory accessible only by themselves and root, with a nonce inside, and include that nonce in their datagram to prove their identity. An ugly hack only usable in limited situations anyway. This patch will also allow a really inexplicable patch to Chromium used by its port to be removed. That patch #defines SCM_CREDENTIALS and SO_PASSCRED to nonsense values, and eliminates Chromium's ability to determine the PID of a datagram sender. Exactly what problems this missing functionality causes Chromium I'm not sure of, but they surely used it for some reason or other. You might think to enhance syslogd, too. Now you can determine the PID as well as the actual credentials of a message sender. At present, syslogd can't do so; any messages you see could be from anyone. I can fill up /var/log/authlog as any user with whatever lies I want. Improving syslogd is obviously of interest to the OpenBSD project, so why not use the ability to determine the credentials and PID of a datagram's sender in some way? As a start, it could at least be useful to log it so that obvious discrepancies are visible. Kind regards, David Mackay
