I wrote:
> BTW, after looking more closely at the buildfarm configure logs, it
> appears that both OpenBSD and NetBSD have getpeereid(), which means
> that they don't use this code at all. It is currently looking to me
> like the HAVE_STRUCT_FCRED and HAVE_STRUCT_SOCKCRED variants are dead
> code.
Further research discloses that:
1. FreeBSD has has getpeereid() since 2001; their CVS logs show that it
was implemented "mostly for compatibility with OpenBSD", so OpenBSD has
had it since even further back.
2. NetBSD implemented getpeereid() as of 5.0.
3. Mac OS X has had getpeereid() since 10.3 or thereabouts.
This means that in fact the control-message variant of auth_peer is dead
code on EVERY modern *BSD variant. So far as I can find, the only
platform on which it is still used is Debian/kFreeBSD, that is Linux
userland running on a FreeBSD kernel: glibc naturally lacks getpeereid,
but the kernel doesn't have SO_PEERCRED, so you end up with the control
message stuff. (This doubtless explains why the portability issues in
the control-message code escaped notice for so long.)
However, FreeBSD does have, and Debian/kFreeBSD does expose,
getsockopt(LOCAL_PEERCRED), which turns out to be functionally
equivalent to SO_PEERCRED: in particular, you can just call it and get
the answer without having to fool with getting the far end to send a
message. This is not only a whole lot cleaner than what we have, but
also could be used to implement libpq's requirepeer option, which is
currently unsupported on such platforms.
So what I'm now thinking is we should rip out the control-message
implementation altogether, and instead use LOCAL_PEERCRED. This is
probably not something to back-patch, but it would make things a lot
cleaner going forward.
Comments?
regards, tom lane