Re: Kerberos delegation support in libpq and postgres_fdw - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Kerberos delegation support in libpq and postgres_fdw |
Date | |
Msg-id | CA+TgmoZNnuvauhU3657gTaV7-Mvp106UY9oK0QbtW9bcrk5ynA@mail.gmail.com Whole thread Raw |
In response to | Re: Kerberos delegation support in libpq and postgres_fdw (Stephen Frost <sfrost@snowman.net>) |
List | pgsql-hackers |
On Fri, Apr 8, 2022 at 11:29 AM Stephen Frost <sfrost@snowman.net> wrote: > > + <term><literal>allow_cred_delegation</literal></term> > > > > First, I again recommend not choosing words at random to abbreviate. > > "delegate_credentials" would be shorter and clearer. Second, I think > > we need to decide whether we envision just having one parameter here > > for every kind of credential delegation that libpq might ever support, > > or whether this is really something specific to GSS. If the latter, > > the name should mention GSS. > > delegate_credentials seems to imply that the server has some kind of > control over the act of delegating credentials, which isn't really the > case. The client has to decide to delegate credentials and it does that > independent of the server- the server side just gets to either accept > those delegated credentials, or ignore them. Oh ... I thought this was a libpq parameter to control the client behavior. I guess I didn't read it carefully enough. > Regarding the client side, it is the case that GSSAPIDelegateCredentials > in ssh defaults to no, so it seems like the next iteration of the patch > should probably include a libpq option similar to that ssh_config > option. As I mentioned before, users already can decide if they'd like > proxyable credentials or not when they kinit, though more generally this > is set as a environment-wide policy, but we can add an option and > disable it by default. +1. > This isn't actually something we have a choice in, really, it's from the > Kerberos library. MEMORY is the library's in-memory credential cache. > Other possible values are FILE:/some/file, DIR:/some/dir, API:, and > others. Documentaton is available here: > https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html Well, I was just going by the fact that this string ("MEMORY:") seems to be being interpreted in our code, not the library. > > I wonder whether we really quite this many cases. But if we do they > > probably need better and more consistent naming. > > I wouldn't want to end up with values that could end up conflicting with > real values that a user might want to specify, so the choice of > 'environment' and empty-value were specifically chosen to avoid that > risk. If we're worried that doing so isn't sufficient or is too > confusing, the better option would likely be to have another GUC that > controls if we unset, ignore, or set the value to what the other GUC > says to set it to. I'm fine with that if you agree. Yeah, I thought of that, and it might be the way to go. I wasn't too sure we needed the explicit-unset behavior as an option, but I defer to you on that. -- Robert Haas EDB: http://www.enterprisedb.com
pgsql-hackers by date: