PATCH: Add GSSAPI ccache_name option to libpq

From: Daniel Carter <danielchriscarter+postgres(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: PATCH: Add GSSAPI ccache_name option to libpq
Date: 2021-04-20 09:37:18
Message-ID: 183cb0c3-30a9-149e-5403-fd36800e8c2b@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
ccache_name.patch text/x-patch 4.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2021-04-20 09:49:34 Tiny update to pg_stat_statements documentation
Previous Message Bharath Rupireddy 2021-04-20 09:36:30 Re: [bug?] Missed parallel safety checks, and wrong parallel safety