> Description of problem:
>
>

krb5-1.18 does not respect KRB5CCNAME in setuid environment, breaking PAM login session setup when using unique kerberos caches

> Version-Release number of selected component (if applicable):
>

krb5-1.18.2-5.el8

>
> How reproducible:
>

100% of time

>
> Steps to Reproduce:
> 1. In sssd.conf set krb5_ccname_template = FILE:/tmp/krb5cc_%U_XXXXXX and in sshd_config set:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
KerberosUniqueCCache=yes

> 2. Put an approriate kerberos id in ~/.k5login so that GSSAPIAuthentication works and so that you can obtain kerberos tickets upon a password ssh login

> 3. Set up a PAM session module that does a setuid call to a program to obtain kerberos service tickets for a service. With fprintf in the external program, log what the value of KRB5CCNAME is and what the ticket cache is set to after calling krb5_cc_default_name(context) and from getenv("KRB5CCNAME")
>

Eg in pam session::
child = fork();
...
if (setuid(pwd->pw_uid) < 0) {
putil_crit(args, "cannot setuid to UID %lu: %s",
(unsigned long) pwd->pw_uid, strerror(errno));
_exit(1);
...
vector_exec_env(args->config->program->strings[0], argv,
(const char * const *) env);

> Actual results:
> using krb5-1.18, the environment variable KRB5CCNAME is the unique cache and the result of krb5_cc_default_name is not the unique cache name.
Eg:
aklog: get_user_realm krb5_cc_default returned 0
aklog: get_user_realm krb5_cc_default name: FILE:/tmp/krb5cc_261937
aklog: get_user_realm env cachename: FILE:/tmp/krb5cc_261937_ckWre5nAzU
aklog: krb5_cc_get_princ returned -1765328189 No credentials cache
found (filename: /tmp/krb5cc_261937)

Furthermore, only the unique cachename actually exists, because that is what sshd/sssd created and then set KRB5CCNAME to.

>
> Expected results:
>
>

Krb5 code, when asked to get the cache, returns the cache as specified in KRB5CCNAME .

> Additional info:
>
>

This appears to be a backwards-incompatible change in krb5-1.18, I am guessing this one:

• setuid programs will automatically ignore environment variables that
  normally affect krb5 API functions, even if the caller does not use
  krb5_init_secure_context().

I can't find anything that actually references what change incorporates that note. Possibly related to ticket 8800 .

I'd consider this a regression based on the documentation and function names and backwards-incompatible change.