Greetings,
* David Christensen (david@pgguru.net) wrote:
> On Wed, Apr 5, 2023 at 3:30 PM Stephen Frost <sfrost@snowman.net> wrote:
> > Per GSS docs, seems like we should be comparing to GSS_C_NO_CREDENTIAL
> > and validating that the gflags has the `deleg_flag` bit set before
> > considering whether there are valid credentials; in practice this might be
> > the same effect (haven't looked at what that symbol actually resolves to,
> > but NULL would be sensible).
> >
> > GSS_C_NO_CREDENTIAL is indeed NULL, but updated to that anyway to be a
> > bit cleaner and also added an explicit check that GSS_C_DELEG_FLAG was
> > set in gflags.
>
> + proxy = NULL;
> [...]
> + if (proxy != GSS_C_NO_CREDENTIAL && gflags & GSS_C_DELEG_FLAG)
>
> We should probably also initialize "proxy" to GSS_C_NO_CREDENTIAL as well,
> yes?
Sure, done, and updated for both auth.c and be-secure-gssapi.c
> > > + /*
> > > + * Set KRB5CCNAME for this backend, so that later calls to
> > gss_acquire_cred
> > > + * will find the proxied credentials we stored.
> > > + */
> > >
> > > So I'm not seeing this in other use in the code; I assume this is just
> > used by the krb5 libs?
> >
> > Not sure I'm following. gss_acquire_cred() is called in
> > src/interfaces/libpq/fe-gssapi-common.c.
>
> I just meant the KRB5CCNAME envvar itself; looks like my assumption was
> right.
Ah, yes, that's correct.
> So on a re-read of the v7 patch, there seems to be a bit of inconsistent
> usage between delegation and proxying; i.e., the field itself is called
> gss_proxy in the gssstatus struct, authentication messages, etc, but the
> setting and docs refer to GSS delegation. Are there subtle distinctions
> between these? It seems like this patch is using them interchangeably, so
> it might be good to settle on one terminology here unless there are already
> well-defined categories for where to use one and where to use the other.
That's a fair point and so I've updated the patch to consistently use
'delegated credentials' and similar to match the Kerberos documentation.
In Kerberos there is *also* the concept of proxied credentials which are
very very similar to delegated credentials (they're actually
"constrainted delegations") but they're not exactly the same and that
isn't what we're doing with this particular patch (though I hope that
once we get support for unconstrained delegation, which is what this
patch is doing, we can then go add support for constrainted
delegations).
Updated patch attached.
Thanks!
Stephen