Re: SSL information view - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: SSL information view
Date
Msg-id CABUevEw_TuFFfa+BE+j+2ys3-LL4SycBzs+emMnzzsAY6QH1CQ@mail.gmail.com
Whole thread Raw
In response to Re: SSL information view  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 12, 2014 at 4:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> As an administrator, I find that you fairly often want to know what
>> your current connections are actually using as SSL parameters, and
>> there is currently no other way than gdb to find that out - something
>> we definitely should fix.
>
> I'm wondering whether it's such a great idea that everybody can see
> everybody else's client DN.  Other than that, no objection to the
> concept.

I was thinking that's mostly the equivalent of a username, which we do
let everybody see in pg_stat_activity.


>> Second, I was planning to implement it by adding fields to
>> PgBackendStatus and thus to BackendStatusArray, booleans directly in
>> the struct and strings similar to how we track for example hostnames.
>> Anybody see a problem with that?
>
> Space in that array is at a premium, and again the client DN seems
> problematic, in that it's not short and has no clear upper bound.
>
> If you were to drop the DN from the proposed view then I'd be fine
> with this.

The text fields, like hostname, are tracked in separate parts of
shared memory with just a pointer in the main array - I assume that's
why, and was planning to do the same. We'd have to cap the length oft
he DN at something though (and document as such), to make it fixed
length.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SSL information view
Next
From: Noah Misch
Date:
Subject: Re: Securing "make check" (CVE-2014-0067)