Re: PATCH: Add GSSAPI ccache_name option to libpq

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Daniel Carter <danielchriscarter+postgres(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PATCH: Add GSSAPI ccache_name option to libpq
Date: 2021-04-21 08:15:14
Message-ID: CA+OCxoxa6g7+dmboJ=t_vBQvLMA4z6USZWiDfJwX4Wh=sJbBkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

On Tue, Apr 20, 2021 at 8:44 PM Daniel Carter <
danielchriscarter+postgres(at)gmail(dot)com> wrote:

> Hi Stephen,
>
> 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).
>

Yes, that's why we'd like it for pgAdmin. When dealing with a
multi-threaded application it becomes a pain keeping credentials for
different users separated; a lot more mucking about with mutexes etc. If we
could specify the credential cache location in the connection string, it
would be much easier (and likely more performant) to securely keep
individual caches for each user.

>
> 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.
>
> Many thanks,
> Daniel
>
>
>

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message SATYANARAYANA NARLAPURAM 2021-04-21 08:20:02 Re: Synchronous commit behavior during network outage
Previous Message houzj.fnst@fujitsu.com 2021-04-21 08:09:25 RE: [bug?] Missed parallel safety checks, and wrong parallel safety