Bug 1264389

Summary:	The ~/.k5identity file is ignored by kinit
Product:	[Fedora] Fedora	Reporter:	Jaroslav Škarvada <jskarvad>
Component:	krb5	Assignee:	Robbie Harwood <rharwood>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	22	CC:	abokovoy, mfuruta, nalin, nathaniel, rharwood
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-09-18 13:16:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.