Re: PATCH: Add GSSAPI ccache_name option to libpq

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Daniel Carter <danielchriscarter+postgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PATCH: Add GSSAPI ccache_name option to libpq
Date: 2021-04-21 17:40:35
Message-ID: 20210421174034.GO20766@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Daniel Carter (danielchriscarter+postgres(at)gmail(dot)com) wrote:
> On 20/04/2021 20:01, Stephen Frost wrote:
> >I'm not necessarily against this, but typically the GSSAPI library
> >provides a way for you to control this using, eg, the KRB5_CCACHE
> >environment variable. Is there some reason why that couldn't be used..?
>
> The original motivation for investigating this was setting up a web app
> which could authenticate to a database server using a Kerberos ticket. Since
> the web framework already needs to create a connection string (with database
> name etc.) to set up the database connection, having an option here for the
> ccache location makes it much more straightforward to specify than having to
> save data out to environment variables (and makes things cleaner if there
> are potentially multiple database connections going on at once in different
> processes).

This is certainly nothing new and the webserver modules supporting this,
like apache's mod_auth_kerb and mod_auth_gssapi, automatically handle
setting the env variables (along with lots of other ones which web apps
have been using for a very long time), so I have to admit that I'm a bit
wary of the argument that this is somehow needed for web-based
applications.

I surely hope that the intent here is to use Negotiate / SPNEGO to
authenticate the user who is connecting to the webserver and then have
credentials delegated (ideally through constrained credential
delegation..) to the web server by the user for the web application to
use to connect to the PG server.

I certainly don't think we should be targetting a solution where the
application is acquiring credentials from the KDC directly using a
user's username/password, that's very strongly discouraged for the very
good reason that it means the user's password is being passed around.

> There may well be a better way of going about this -- it's just that I can't
> currently see an obvious way to get this kind of setup working using only
> the environment variable.

Perhaps you could provide a bit more information about what you're
specifically doing here? Again, with something like apache's
mod_auth_gssapi, it's a matter of just installing that module and then
the user will be authenticated by the web server itself, including
managing of delegated credentials, setting of the environment variables,
and the web application shouldn't have to do anything but use libpq to
request a connection and if PG's configured with gssapi auth, it'll all
'just work'. Only thing I can think of offhand is that you might have
to take AUTH_USER and pass that to libpq as the user's username to
connect with and maybe get from the user what database to request the
connection to..

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2021-04-21 18:36:24 Re: when the startup process doesn't
Previous Message Tom Lane 2021-04-21 16:30:22 Re: WIP: WAL prefetch (another approach)