Bug 1264389 - The ~/.k5identity file is ignored by kinit
The ~/.k5identity file is ignored by kinit
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Robbie Harwood
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-09-18 06:43 EDT by Jaroslav Škarvada
Modified: 2015-09-18 09:16 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-18 09:16:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jaroslav Škarvada 2015-09-18 06:43:24 EDT
Description of problem:
The ~/.k5identity file is ignored by kinit. I think it shouldn't be, because the ccselect plugin with k5identity module seems to be built-in and not disabled.

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

How reproducible:

Steps to Reproduce:
1. useradd user1
2. su - user1
3. echo user2@EXAMPLE.COM > ~/.k5identity
4. kinit

Actual results:
kinit: Client 'user1@EXAMPLE.COM' not found in Kerberos database while getting initial credentials

Expected results:
Credentials acquired for user2@EXAMPLE.COM.

Additional info:
Explicit specification of user works, e.g. the following works:
$ kinit user2

It seems the ~/.k5identity file is not read:
$ strace -fo trace kinit
$ grep k5identity trace

Also no ~/.* file is accessed:
$ grep open trace

According to the documentation (e.g. man krb5.conf), the built-in k5identity module of ccselect interface "Uses a .k5identity file in the user's home directory to select a client principal".
Comment 1 Alexander Bokovoy 2015-09-18 07:26:36 EDT
kinit doesn't use krb5_cc_select() function which is the entry point to call ccselect plugins. Only GSSAPI is doing that via kg_cred_resolve() internally, so only code using GSSAPI (gss_init_sec_context() or gss_accept_sec_context()) would be using ccselect interface.

You can check that ccselect interface is indeed called by GSSAPI by running gss-server/gss-client pair:

1. Start a server:
# KRB5_TRACE=/dev/stderr gss-server -keytab /etc/krb5.keytab -verbose host

2. Start a client:
$ KRB5_TRACE=/dev/stderr strace gss-client  `hostname` host foo 2>&1|grep k5identity
open("/home/abokovoy/.k5identity", O_RDONLY) = 5
write(4, "[10138] 1442575560.404298: ccsel"..., 193[10138] 1442575560.404298: ccselect module k5identity chose cache KEYRING:persistent:1000:krb_ccache_DQayVgb with client principal abokovoy@VDA.LI for server principal host/onega.vda.li@VDA.LI
Comment 2 Jaroslav Škarvada 2015-09-18 08:12:37 EDT
Thanks for info. Is there any way how to setup it to work with different local user name in Red Hat network? My local user name is different from my kerberos user name and I would like to do just 'kinit' not 'kinit KRB_USR_NAME'. I was unable to find anything related in the documentation (not counting .k5identity), but maybe I just haven't looked carefully.
Comment 3 Alexander Bokovoy 2015-09-18 08:28:27 EDT
Yes, just use recent SSSD as Jakub explains in his blog post: https://jhrozek.wordpress.com/2015/07/17/get-rid-of-calling-manually-calling-kinit-with-sssds-help/
Comment 4 Jaroslav Škarvada 2015-09-18 09:12:21 EDT
OK thanks for info. I thought such functionality is in kerberos or that it's possible to do it with some auth_to_local mapping magic. But I wasn't successful to setup it. I can also create shell alias or add shell wrapper in case it's not directly possible in kerberos. Process/close this bug at your discretion.
Comment 5 Alexander Bokovoy 2015-09-18 09:16:34 EDT
Thanks. Closing.

Note You need to log in before you can comment on or make changes to this bug.