Thread

1. server authentication over Unix-domain sockets

   Peter Eisentraut <peter_e@gmx.net> — 2010-05-30T11:00:03Z

   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?
   
   

2. Re: server authentication over Unix-domain sockets

   Magnus Hagander <magnus@hagander.net> — 2010-06-11T11:53:31Z

   On Sun, May 30, 2010 at 13:00, Peter Eisentraut <peter_e@gmx.net> 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?
   >
   >
   >
   > --
   > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
   > To make changes to your subscription:
   > http://www.postgresql.org/mailpref/pgsql-hackers
   >
   >
   
   
   
   -- 
    Magnus Hagander
    Me: http://www.hagander.net/
    Work: http://www.redpill-linpro.com/
   
   

3. Re: server authentication over Unix-domain sockets

   Magnus Hagander <magnus@hagander.net> — 2010-06-11T11:55:25Z

   On Sun, May 30, 2010 at 13:00, Peter Eisentraut <peter_e@gmx.net> 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?
   
   I like it. ISTM like something that would be very useful - an easy way
   to get a fair amount of extra security in the case of local
   connections, at almost zero cost. Just an "export
   PGREQUIREPEER=postgres" in .profile goes a long way :-)
   
   
   
   -- 
    Magnus Hagander
    Me: http://www.hagander.net/
    Work: http://www.redpill-linpro.com/
   
   

4. Re: server authentication over Unix-domain sockets

   Stephen Frost <sfrost@snowman.net> — 2010-06-11T12:07:26Z

   * Peter Eisentraut (peter_e@gmx.net) wrote:
   > The patch needs some portability work and possible refactoring because
   > of that, but before I embark on that, comments on the concept?
   
   I definitely like the idea but I dislike requiring the user to do
   something to implement it.  Thinking about how packagers might want to
   use it, could we make it possible to build it defaulted to a specific
   value (eg: 'postgres' on Debian) and allow users a way to override
   and/or unset it?
   
   Having the option wouldn't do much unless users know of it and use it
   and it strikes that will very often not be the case.
   
   I'm impartial towards whatever PG wants to do with the default, just so
   long as packagers can override it and set it to something specific.
   Also, to that end, it's got to be name-based.  Exim in Debian did
   something similar and actually tried to force a particular UID..  that
   was horrid. :)  On Debian, at least, the user is almost always
   'postgres', but the UID will vary depending on exactly when the packages
   were installed (before or after other system-user-creating packages).
   
   	Thanks,
   
   		Stephen
   

5. Re: server authentication over Unix-domain sockets

   Magnus Hagander <magnus@hagander.net> — 2010-06-11T12:08:59Z

   On Fri, Jun 11, 2010 at 14:07, Stephen Frost <sfrost@snowman.net> wrote:
   > * Peter Eisentraut (peter_e@gmx.net) wrote:
   >> The patch needs some portability work and possible refactoring because
   >> of that, but before I embark on that, comments on the concept?
   >
   > I definitely like the idea but I dislike requiring the user to do
   > something to implement it.  Thinking about how packagers might want to
   > use it, could we make it possible to build it defaulted to a specific
   > value (eg: 'postgres' on Debian) and allow users a way to override
   > and/or unset it?
   
   Well, even if we don't put that in, the packager could export a global
   PGREQUIREPEER environment variable.
   
   
   > Having the option wouldn't do much unless users know of it and use it
   > and it strikes that will very often not be the case.
   >
   > I'm impartial towards whatever PG wants to do with the default, just so
   > long as packagers can override it and set it to something specific.
   > Also, to that end, it's got to be name-based.  Exim in Debian did
   > something similar and actually tried to force a particular UID..  that
   > was horrid. :)  On Debian, at least, the user is almost always
   > 'postgres', but the UID will vary depending on exactly when the packages
   > were installed (before or after other system-user-creating packages).
   
   Oh yes, absolutely name-based.
   
   -- 
    Magnus Hagander
    Me: http://www.hagander.net/
    Work: http://www.redpill-linpro.com/
   
   

6. Re: server authentication over Unix-domain sockets

   Stephen Frost <sfrost@snowman.net> — 2010-06-11T12:11:57Z

   * Magnus Hagander (magnus@hagander.net) wrote:
   > On Fri, Jun 11, 2010 at 14:07, Stephen Frost <sfrost@snowman.net> wrote:
   > > I definitely like the idea but I dislike requiring the user to do
   > > something to implement it.  Thinking about how packagers might want to
   > > use it, could we make it possible to build it defaulted to a specific
   > > value (eg: 'postgres' on Debian) and allow users a way to override
   > > and/or unset it?
   > 
   > Well, even if we don't put that in, the packager could export a global
   > PGREQUIREPEER environment variable.
   
   Yeahhhh, no, that's a crappy solution, sorry. :)  I've been down that
   road with people trying to monkey with /etc/bashrc; oh wait, not
   everyone uses bash, and having every package screw with that stuff is
   equally horrible.  Admittedly, in this specific case, Debian could
   implement what you're talking about in it's wrapper system, maybe, but I
   still don't like it and if people don't use the wrapper (I can imagine
   cases why that might happen, tho I havn't ever had to myself), they
   wouldn't get the benefit..
   
   	Thanks,
   
   		Stephen
   

7. Re: server authentication over Unix-domain sockets

   Kouhei Kaigai <kaigai@ak.jp.nec.com> — 2010-06-21T04:51:40Z

   (2010/06/11 21:11), Stephen Frost wrote:
   > * Magnus Hagander (magnus@hagander.net) wrote:
   >> On Fri, Jun 11, 2010 at 14:07, Stephen Frost<sfrost@snowman.net>  wrote:
   >>> I definitely like the idea but I dislike requiring the user to do
   >>> something to implement it.  Thinking about how packagers might want to
   >>> use it, could we make it possible to build it defaulted to a specific
   >>> value (eg: 'postgres' on Debian) and allow users a way to override
   >>> and/or unset it?
   >>
   >> Well, even if we don't put that in, the packager could export a global
   >> PGREQUIREPEER environment variable.
   > 
   > Yeahhhh, no, that's a crappy solution, sorry. :)  I've been down that
   > road with people trying to monkey with /etc/bashrc; oh wait, not
   > everyone uses bash, and having every package screw with that stuff is
   > equally horrible.  Admittedly, in this specific case, Debian could
   > implement what you're talking about in it's wrapper system, maybe, but I
   > still don't like it and if people don't use the wrapper (I can imagine
   > cases why that might happen, tho I havn't ever had to myself), they
   > wouldn't get the benefit..
   > 
   Are you suggesting the packager enforces a certain unix user on the
   installation time, although 'postgres' shall be used in most cases?
   
   Let's back to the purpose of the feature.
   In my understanding, it provides the client process the way to verity
   user identifier of the server process before sending password.
   Indeed, if we provide a default value of the "requirepeer" using
   environment variable, the client process can override its own setting.
   But is there any problem?
   
   This option allows the client process to specify an expected user
   identifier of the server process, then libpq closes the connection
   if not matched.
   Even if the default shall be given from the system default, the
   client can provide an explicit alternative in the connection string.
   Is there any fundamental differences to the environment variable?
   
   Thanks,
   -- 
   KaiGai Kohei <kaigai@ak.jp.nec.com>
   
   

8. Re: server authentication over Unix-domain sockets

   Peter Eisentraut <peter_e@gmx.net> — 2010-06-21T20:48:00Z

   On fre, 2010-06-11 at 08:07 -0400, Stephen Frost wrote:
   > Having the option wouldn't do much unless users know of it and use it
   > and it strikes that will very often not be the case.
   
   That situation is the same as with SSL over TCP/IP with certificate
   validation.  I don't think we can make either of these the default
   without risking breaking a lot of things.
   
   
   

9. Re: server authentication over Unix-domain sockets

   Kouhei Kaigai <kaigai@ak.jp.nec.com> — 2010-06-22T00:37:03Z

   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 connect to 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>
   
   

10. Re: server authentication over Unix-domain sockets

    Peter Eisentraut <peter_e@gmx.net> — 2010-07-01T02:30:09Z

    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.
    

11. Re: server authentication over Unix-domain sockets

    Kouhei Kaigai <kaigai@ak.jp.nec.com> — 2010-07-02T07:35:50Z

    (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>
    
    

12. Re: server authentication over Unix-domain sockets

    Magnus Hagander <magnus@hagander.net> — 2010-07-02T08:16:15Z

    On Fri, Jul 2, 2010 at 8:35 AM, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
    > (2010/07/01 11:30), Peter Eisentraut wrote:
    > 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.
    
    Win32 never has HAVE_UNIX_SOCKET.
    
    Cygwin might though, I recall some old discussion about that - can't
    remember the outcome though, and I can't find it right now.
    
    > I'd like someone to try to build with this patch on win32 platform,
    > and report it.
    
    I think cygwin may be the more important one here.
    
    -- 
     Magnus Hagander
     Me: http://www.hagander.net/
     Work: http://www.redpill-linpro.com/
    
    

13. Re: server authentication over Unix-domain sockets

    Peter Eisentraut <peter_e@gmx.net> — 2010-07-02T16:30:47Z

    On fre, 2010-07-02 at 09:16 +0100, Magnus Hagander wrote:
    > On Fri, Jul 2, 2010 at 8:35 AM, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
    > > (2010/07/01 11:30), Peter Eisentraut wrote:
    > > 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.
    > 
    > Win32 never has HAVE_UNIX_SOCKET.
    > 
    > Cygwin might though, I recall some old discussion about that - can't
    > remember the outcome though, and I can't find it right now.
    
    Cygwin doesn't define WIN32 anyway.
    
    
    
    

14. Re: server authentication over Unix-domain sockets

    Andrew Dunstan <andrew@dunslane.net> — 2010-07-02T16:39:18Z

    
    Peter Eisentraut wrote:
    >>> 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.
    >>>       
    >> Win32 never has HAVE_UNIX_SOCKET.
    >>
    >> Cygwin might though, I recall some old discussion about that - can't
    >> remember the outcome though, and I can't find it right now.
    >>     
    >
    > Cygwin doesn't define WIN32 anyway.
    >
    >   
    
    Indeed, and we've been very careful to keep it that way.
    
    cheers
    
    andrew
    
    
    

15. Re: server authentication over Unix-domain sockets

    Kouhei Kaigai <kaigai@ak.jp.nec.com> — 2010-07-09T03:36:48Z

    (2010/07/03 1:39), Andrew Dunstan wrote:
    > 
    > 
    > Peter Eisentraut wrote:
    >>>> 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.
    >>> Win32 never has HAVE_UNIX_SOCKET.
    >>>
    >>> Cygwin might though, I recall some old discussion about that - can't
    >>> remember the outcome though, and I can't find it right now.
    >>
    >> Cygwin doesn't define WIN32 anyway.
    >>
    > 
    > Indeed, and we've been very careful to keep it that way.
    > 
    
    Sorry for the late responding.
    
    I marked this patch 'ready for committer'.
    
    Thanks,
    -- 
    KaiGai Kohei <kaigai@ak.jp.nec.com>