PATCH: Add GSSAPI ccache_name option to libpq - Mailing list pgsql-hackers

From Daniel Carter
Subject PATCH: Add GSSAPI ccache_name option to libpq
Date
Msg-id 183cb0c3-30a9-149e-5403-fd36800e8c2b@gmail.com
Whole thread Raw
Responses Re: PATCH: Add GSSAPI ccache_name option to libpq  (Aleksander Alekseev <aleksander@timescale.com>)
Re: PATCH: Add GSSAPI ccache_name option to libpq  (Dave Page <dpage@pgadmin.org>)
Re: PATCH: Add GSSAPI ccache_name option to libpq  (Stephen Frost <sfrost@snowman.net>)
Re: PATCH: Add GSSAPI ccache_name option to libpq  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Hi,

This is a small patch (against master) to allow an application using 
libpq with GSSAPI authentication to specify where to fetch the 
credential cache from -- it effectively consists of a new field in 
PQconninfoOptions to store this data and (where the user has specified a 
ccache location) a call into the gss_krb5_ccache_name function in the 
GSSAPI library.

It's my first go at submitting a patch -- it works as far as I can tell, 
but I suspect there will probably still be stuff to fix before it's 
ready to use!

As far as I'm concerned this is working (the code compiles successfully 
following "./configure --with-gssapi --enable-cassert", and seems to 
work for specifying the ccache location without any noticeable errors).

I hope there shouldn't be anything platform-specific here (I've been 
working on Ubuntu Linux but the only interactions with external 
applications are via the GSSAPI library, which was already in use).

The dispsize value for ccache_name is 64 in this code (which seems to be 
what's used with other file-path-like parameters in the existing code) 
but I'm happy to have this corrected if it needs a different value -- as 
far as I can tell this is just for display purposes rather than anything 
critical in terms of actually storing the value?

If no ccache_name is specified in the connection string then it defaults 
to NULL, which means the gss_krb5_ccache_name call is not made and the 
current behaviour (of letting the GSSAPI library work out the location 
of the ccache) is not changed.

Many thanks,
Daniel


Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety
Next
From: Greg Nancarrow
Date:
Subject: Tiny update to pg_stat_statements documentation