Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Agreed. Requiring client root certificate checking is heavy-handed.
>
> There seems to be some confusion here. I didn't think anyone was
> proposing that we force every installation to require client root
> certificate checking. Wha
Mark Mielke wrote:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>
>>> Agreed. Requiring client root certificate checking is heavy-handed.
>>>
>> There seems to be some confusion here. I didn't think anyone was
>> proposing that we force every installation to require cli
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'
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
Mark Mielke wrote:
> Magnus Hagander wrote:
>> Mark Mielke wrote:
>>
>>>
>>> I have done this for my own application before. Although the client and
>>> server use standard TLS 1.0 to speak to each other with a required
>>> authentication of RSA 1024-bit and a required encryption of AES 128-bit,
On Fri, 2007-12-28 at 20:20 -0500, Greg Smith wrote:
> On Sat, 29 Dec 2007, Simon Riggs wrote:
>
> > System Shutdown
> > System shuts down, postmaster shuts down, archiver works furiously until
> > the end trying to archive things away. Archiver gets caught half way
> > through copy, so crashes, l
On Sat, 29 Dec 2007 12:45:26 +0100
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> That is exactly my point. The server can never know if the client has
> actually verified anything. It can provide the client with the *means*
> to verify things, but it can't enforce it.
I know this is probably obviou
Magnus Hagander wrote:
Mark Mielke wrote:
Why are you even using a password in this case, and not just key-based
auth? Wouldn't that be even easier and more secure?
Users of this product don't have keys - they have passwords. The
username/password is for per-user authentication. The u
D'Arcy J.M. Cain wrote:
- 1: How does the client assure that the postmaster is legit
- 2: How does the postmaster assure that the client is legit
And neither answers the original problem:
3. How can the sysadmin prevent a malicious local user from hijacking
the sockets if the postm
On Sat, 29 Dec 2007 10:38:13 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> D'Arcy J.M. Cain wrote:
> > - 1: How does the client assure that the postmaster is legit
> > - 2: How does the postmaster assure that the client is legit
>
> And neither answers the original problem:
Which se
* D'Arcy J.M. Cain ([EMAIL PROTECTED]) wrote:
> > Probably the first answer is not to run postgres on a machine with
> > untrusted users, but that's not always possible. Maybe we can't find a
> > simple cross-platform answer, but that doesn't mean we should not look
> > at platform-specific answ
Andrew Dunstan wrote:
D'Arcy J.M. Cain wrote:
- 1: How does the client assure that the postmaster is legit
- 2: How does the postmaster assure that the client is legit
And neither answers the original problem:
3. How can the sysadmin prevent a malicious local user from hijacking
the soc
Magnus Hagander wrote:
> 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 conne
Mark Mielke wrote:
Andrew Dunstan wrote:
D'Arcy J.M. Cain wrote:
- 1: How does the client assure that the postmaster is legit
- 2: How does the postmaster assure that the client is legit
And neither answers the original problem:
3. How can the sysadmin prevent a malicious local user f
Andrew Dunstan wrote:
It might well be useful for us to look at drafting an SELinux policy,
even if it's not universal. After all, this situation is precisely the
sort of thing that SELinux is about, ISTM.
http://code.google.com/p/sepgsql/
???
Sincerely,
Joshua D. Drake
-
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It might well be useful for us to look at drafting an SELinux policy,
There already is one. However, I'm not sure that it's ever been
reviewed by anyone who's Postgres-savvy (I certainly haven't looked
at it:-(). It would be useful for that to happen
Mark Mielke <[EMAIL PROTECTED]> writes:
> What has come out for me is that this isn't UNIX socket specific at all
> (although there may be UNIX socket specific options available). The
> standard PostgreSQL port is above 1024, and anybody could
> bind()/listen()/accept() on it, assuming it is not
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
http://code.google.com/p/sepgsql/
???
Getting that to work required some obtrusive changes to the source code,
which they've only done to 8.2.4. Even that doesn't seem to be
production-quality and it's not clear how that will make its way into
ne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 29 Dec 2007 14:40:29 -0500 (EST)
Greg Smith <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Dec 2007, Joshua D. Drake wrote:
>
> > http://code.google.com/p/sepgsql/
> > ???
>
> Getting that to work required some obtrusive changes to the source
> cod
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
"they've" has the potential to be "we"... As I recall the individual
made a reasonable effort to introduce the work that he was doing to the
community.
After a bit of hindsight research, I think SE-PostgreSQL suffered from two
timing problems combin
Tom Lane wrote:
> This is basically the same old mutual authentication problem that SSL
> was designed to solve by using certificates. I don't think we have
> either the need or the expertise to re-invent that wheel.
>
> ISTM we have these action items:
>
> 1. Improve the code so that SSL authen
21 matches
Mail list logo
