(2010/07/01 11:30), Peter Eisentraut wrote:
> On tis, 2010-06-22 at 09:37 +0900, KaiGai Kohei wrote:
>> As you described at the source code comments as follows,
>> it is not portable except for Linux due to the getsockopt() API.
>>
>> + // TODO: currently Linux-only code, needs to be made
>> + // portable; see backend/libpq/auth.c
>>
>> I expect it shall be fixed (using the code come from ident_unix()?)
>> before committing.
>
> Updated patch attached.
>
> Note that the code that gets the user ID from the other end of a socket
> appears to have two different modes of operation. On some platforms
> (Linux, OpenBSD, Solaris), you call a function and get the answer. On
> some other platforms (other BSDs?), you need to send a packet and read
> the answer. I don't have any possibility to test the latter approach,
> and it seemed a bit complicated to code "blindly". So I have omitted
> support for that, but if someone else wants to do the porting, that is
> of course possible.
>
I checked the revised patch.
The part to obtain user id of the peer is identical with ident_unix()
on the backend, so I believe it will work well, although I don't have
test environment except for Linux.
>> I'd like to point out one other point.
>> It uses getpwuid() to translate a user identifier into a user name,
>> but it returns a pointer of the static variable within glibc.
>> So, it is not thread-safe. I recommend to use getpwnam_r() instead.
>
> Good catch. pqGetpwuid() was actually the right function to use.
>
I have a question.
The pqGetpwuid() is enclosed by #ifndef WIN32 ... #endif, although
this patch encloses the section to obtain user id of the peer by
#ifdef HAVE_UNIX_SOCKETS ... #endif.
Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.
I'd like someone to try to build with this patch on win32 platform,
and report it.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>