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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers