Re: server authentication over Unix-domain sockets - Mailing list pgsql-hackers

I've checked on this patch.

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.


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.

Except for the issue, it looks to me fine.

* The patch can be applied on the head of the git repository.
* We can build the code without any warnings/errors.
* It works as described in the documentation.
 [kaigai@saba ~]$ php -r 'pg_connect("dbname=postgres requirepeer=xxxx");' PHP Warning:  pg_connect(): Unable to
connectto PostgreSQL server: invalid connection option "requirepeer" in Command line code on line 1
 
=> Existing library, so not supported.
 [kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \                  php -r 'pg_connect("dbname=postgres
requirepeer=xxxx");'PHP Warning:  pg_connect(): Unable to connect to PostgreSQL server: requirepeer failed (actual:
kaigai!= required: xxxx) in Command line code on line 1 LOG:  incomplete startup packet
 
=> Patched library, so it prevent unexpected user-id of server process
 [kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \                  php -r 'pg_connect("dbname=postgres
requirepeer=kaigai");'
=> Patched library, so it does not prevent anything for the expected user-id.
 [kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \                  php -r 'pg_connect("dbname=postgres");'
=> No "requirepeer", so it does not prevent anything.
 [kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \                  env PGREQUIREPEER=xyz php -r
'pg_connect("dbname=postgres");'PHP Warning:  pg_connect(): Unable to connect to PostgreSQL server: requirepeer failed
(actual:kaigai != required: xyz) in Command line code on line 1 LOG:  incomplete startup packet
 
=> PGREQUIREPEER environment variable, instead of "requirepeer" option. Same result.
 [kaigai@saba ~]$ env LD_LIBRARY_PATH=/usr/local/pgsql/lib/ \                  env PGREQUIREPEER=kaigai php -r
'pg_connect("dbname=postgres");'
=> PGREQUIREPEER environment variable, instead of "requirepeer" option. Same result.

Thanks,

(2010/05/30 20:00), Peter Eisentraut wrote:
> It has been discussed several times in the past that there is no way for
> a client to authenticate a server over Unix-domain sockets.  So
> depending on circumstances, a local user could easily insert his own
> server and collect passwords and data.  Suggestions for possible
> remedies included:
> 
> You can put the socket file in a sufficiently write-protected directory.
> But that would strongly deviate from the default setup, and anyway the
> client still cannot readily verify that the server is the right one.
> 
> You can also run SSL over Unix-domain sockets.  This is currently
> disabled in the code, but it would work just fine.  But it's obviously
> kind of awkward, and the connection overhead was noticeable in tests.
> 
> Then it was suggested to use the local "ident" mechanism in reverse, so
> the client could verify what user the server runs under.  I have
> implemented a prototype of this.  You can put, e.g.,
> 
> requirepeer=postgres
> 
> into the connection parameters, and the connection will be rejected
> unless the process at the other end of the socket is running as
> postgres.
> 
> The patch needs some portability work and possible refactoring because
> of that, but before I embark on that, comments on the concept?
> 
> 
> 
> 
> 


-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>