Bug 1264389 - The ~/.k5identity file is ignored by kinit
Summary: The ~/.k5identity file is ignored by kinit
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: krb5
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Robbie Harwood
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-18 10:43 UTC by Jaroslav Škarvada
Modified: 2018-09-07 10:38 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-09-18 13:16:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jaroslav Škarvada 2015-09-18 10:43:24 UTC
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):
krb5-workstation-1.13.2-5.fc22.x86_64

How reproducible:
Always

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

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

Expected results:
Credentials acquired for user2.

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 11:26:36 UTC
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 for server principal host/onega.vda.li

Comment 2 Jaroslav Škarvada 2015-09-18 12:12:37 UTC
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 12:28:27 UTC
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 13:12:21 UTC
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 13:16:34 UTC
Thanks. Closing.


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