Skip site navigation (1) Skip section navigation (2)

Re: server authentication over Unix-domain sockets

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: server authentication over Unix-domain sockets
Date: 2010-07-01 02:30:09
Message-ID: 1277951409.27966.49.camel@vanquo.pezone.net (view raw or flat)
Thread:
Lists: pgsql-hackers
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'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.

Attachment: serverauth-requirepeer.patch
Description: text/x-patch (6.4 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-07-01 02:39:54
Subject: Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby
Previous:From: Tom LaneDate: 2010-07-01 02:21:52
Subject: Re: Keeping separate WAL segments for each database

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group