Re: Fixing cache pollution in the Kerberos test suite

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jacob Champion <pchampion(at)vmware(dot)com>
Cc: "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fixing cache pollution in the Kerberos test suite
Date: 2021-01-25 19:36:21
Message-ID: 1897402.1611603381@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Jacob Champion <pchampion(at)vmware(dot)com> writes:
>> Interesting. I'm running Ubuntu 20.04:

> Hmm. I'll poke harder.

Ah ... on both RHEL8 and Fedora 33, I find this:

--- snip ---
$ cat /etc/krb5.conf.d/kcm_default_ccache
# This file should normally be installed by your distribution into a
# directory that is included from the Kerberos configuration file (/etc/krb5.conf)
# On Fedora/RHEL/CentOS, this is /etc/krb5.conf.d/
#
# To enable the KCM credential cache enable the KCM socket and the service:
# systemctl enable sssd-secrets.socket sssd-kcm.socket
# systemctl start sssd-kcm.socket
#
# To disable the KCM credential cache, comment out the following lines.

[libdefaults]
default_ccache_name = KCM:
--- snip ---

Even more interesting, that service seems to be enabled by default
(I'm pretty darn sure I didn't ask for it...)

However, this doesn't seem to explain why the test script isn't
causing a global state change. Whether the state is held in a
file or the sssd daemon shouldn't matter, it seems like.

Also, it looks like the test causes /tmp/krb5cc_<uid> to get
created or updated despite this setting. If I force klist
to look at that:

$ KRB5CCNAME=/tmp/krb5cc_1001 klist
Ticket cache: FILE:/tmp/krb5cc_1001
Default principal: test1(at)EXAMPLE(dot)COM

Valid starting Expires Service principal
01/25/21 14:31:57 01/26/21 14:31:57 krbtgt/EXAMPLE(dot)COM(at)EXAMPLE(dot)COM
01/25/21 14:31:57 01/26/21 14:31:57 postgres/auth-test-localhost.postgresql.example.com@
Ticket server: postgres/auth-test-localhost(dot)postgresql(dot)example(dot)com(at)EXAMPLE(dot)COM

where the time corresponds to my having just run the test again.

So I'm still mightily confused, but it is clear that the test's
kinit is touching a file it shouldn't.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2021-01-25 19:50:47 Re: Fixing cache pollution in the Kerberos test suite
Previous Message Fabrízio de Royes Mello 2021-01-25 19:34:17 Re: [UNVERIFIED SENDER] Re: Minimal logical decoding on standbys