Re: log ssl mode with connections? - Mailing list pgsql-hackers

From Henry B. Hotz
Subject Re: log ssl mode with connections?
Date
Msg-id DDE7D5A7-C1C9-45E9-87F9-5D00CACB5865@jpl.nasa.gov
Whole thread Raw
In response to Re: log ssl mode with connections?  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Anyone making those kind of decisions probably wants a generic  
"connection is encrypted" flag.  It could be true if a GSSAPI  
connection has negotiated use of a security layer.

Of course I don't have my GSSAPI patches working as well as the SASL  
ones were yet, and I haven't started on adding security layers yet  
either.

On Jan 30, 2007, at 12:56 PM, Magnus Hagander wrote:

> On Tue, Jan 30, 2007 at 12:35:01PM -0500, Kris Jurka wrote:
>>
>>
>> On Tue, 30 Jan 2007, Andrew Dunstan wrote:
>>
>>> If I am allowing both SSL and non-SSL I might like to know which  
>>> is used
>>> by a particular connection.
>>>
>>
>> Other places I've heard people ask for this info:
>>
>> 1) pg_stat_activity to see who's currently connected and how.
>>
>> 2) Via a function (boolean am_i_using_ssl()) so they can make  
>> security
>> decisions in views or procedural code.
>
> That information is available to the client in the form of the API  
> call
> PQgetssl(). It will return NULL if no SSL is in use, or something  
> other
> than NULL if it is (a SSL * pointer, but you don't need to know  
> that if
> you just want to know if you're on SSL or not).
> IIRC it was originally disucssed to put it as a function callable, but
> it was decided that it makes a lot more sense to provide it in the
> client library. I don't know how many other client libraries  
> provide the
> SSL information stuff.
>
> //Magnus
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Column storage positions
Next
From: Gavin Sherry
Date:
Subject: Re: Status of Hierarchical Queries