Re: Fixing cache pollution in the Kerberos test suite - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing cache pollution in the Kerberos test suite
Date
Msg-id 1894698.1611600541@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing cache pollution in the Kerberos test suite  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Fixing cache pollution in the Kerberos test suite  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Jacob Champion (pchampion@vmware.com) wrote:
>> I was running tests with a GSS-enabled stack, and ran into some very
>> long psql timeouts after running the Kerberos test suite. It turns out
>> the suite pushes test credentials into the user's global cache, and
>> these no-longer-useful credentials persist after the suite has
>> finished. (You can see this in action by running the test/kerberos
>> suite and then running `klist`.) This leads to long hangs, I assume
>> while the GSS implementation tries to contact a KDC that no longer
>> exists.
>> Attached is a patch that initializes a local credentials cache inside
>> tmp_check/krb5cc, and tells psql to use it via the KRB5CCNAME envvar.
>> This prevents the global cache pollution. WDYT?

> Ah, yeah, that generally seems like a good idea.

Yeah, changing global state is just awful.  However, I don't
actually see any change here (RHEL8):

$ klist
klist: Credentials cache 'KCM:1001' not found
$ make check
...
Result: PASS
$ klist
klist: Credentials cache 'KCM:1001' not found

I suppose in an environment where someone was really using Kerberos,
the random kinit would be more of a problem.

Also, why are you only setting the ENV variable within narrow parts
of the test script?  I'd be inclined to enforce it throughout.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Fixing cache pollution in the Kerberos test suite
Next
From: Jacob Champion
Date:
Subject: Re: Fixing cache pollution in the Kerberos test suite