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

Re: Spoofing as the postmaster

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spoofing as the postmaster
Date: 2007-12-29 11:53:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Martijn van Oosterhout wrote:
> On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote:
>> We already *do* allow the DBA to choose this, no? If you put the root
>> certificate on the client, it *will* verify the server cert, and it
>> *will* refuse to connect to a server that can't present a trusted root cert.
> I think Tom's point is that we don't allow this for connections over a
> Unix Domain socket. And thus we should remove the asymmetry so the
> verification can work for them also.

If that's where we still are, then I'm all for that provided it doesn't
add a whole lot of complexity, as I think I said before. I thought we
were now talking general SSL connections. That could be where I lost the
thread :-)

> Personally I quite liked the idea of having a serveruser=foo which is
> checked by getting the peer credentials. Very low cost, quick setup
> solution.

It would still only tell you the user and not the postmaster ;-) But
yes, it does help in the unix domain case (but not TCP-over-localhost).

Either that, or a function that returns the peer credentials if
available - like we have for SSL today. Then the client could do some
more advanced checking if necessary - like allowing multiple different
accounts if wanted.


In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2007-12-29 11:57:26
Subject: Re: Spoofing as the postmaster
Previous:From: Martijn van OosterhoutDate: 2007-12-29 11:49:08
Subject: Re: Spoofing as the postmaster

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