Description of problem: Maybe this issue is caused by the not yet implemented kernel keyring cache, but rather file it to be sure. Version-Release number of selected component (if applicable): krb5-1.11.3-21.el7 How reproducible: always Steps to Reproduce: 1. Create a kdc principals: # kdb5_util -s create ... # kadmin.local kadmin.local: ank alice ... kadmin.local: ank -randkey host/rhel7.pkis.net ... kadmin.local: ktadd host/rhel7.pkis.net ... kadmin.local: q # # useradd alice # useradd bob # service krb5kdc start ... 2. Allow alice to use ksu # su - alice $ echo 'alice' >.k5login $ exit 3. Try ksu # su - bob $ kinit alice Password for alice: $ klist Ticket cache: KEYRING:persistent:1001:1001 Default principal: alice Valid starting Expires Service principal 10/04/2013 15:47:59 10/05/2013 15:47:59 krbtgt/EXAMPLE.COM renew until 10/04/2013 15:47:59 $ ksu alice WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Kerberos password for alice: : No password given Authentication failed. Actual results: ksu does not work as expected Expected results: ksu works as in RHEL-6: [bob@rhel6 ~]$ ksu alice Authenticated alice Account alice: authorization for alice successful Changing uid to alice (500) [alice@rhel6 bob]$ id uid=500(alice) gid=500(alice) groups=500(alice) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Additional info:
While this is still being worked on, please include the versions of keyutils and the running kernel, as they affect what's going on underneath Kerberos. As of 3.10.0-34.el7, I don't see a 'big_key' kernel module and 'keyctl get_persistent @s `id -u`' fails with an "operation not supported" error, so the kernel-side bits apparently aren't there yet. This is a different bug, though, due in part to patches we added to ksu way back when FILE ccaches were the norm.
I reproduced the issue on my updated RHEL-7 box with there packages: # rpm -qa krb5\* kernel keyutils krb5-appl-clients-1.0.3-7.el7.x86_64 keyutils-1.5.8-1.el7.x86_64 kernel-3.10.0-34.el7.x86_64 krb5-debuginfo-1.11.3-24.el7.x86_64 krb5-server-1.11.3-24.el7.x86_64 krb5-workstation-1.11.3-24.el7.x86_64 krb5-appl-servers-1.0.3-7.el7.x86_64 krb5-server-ldap-1.11.3-24.el7.x86_64 krb5-devel-1.11.3-24.el7.x86_64 krb5-libs-1.11.3-24.el7.x86_64
ksu doesn't seem to understand credential cache collections when it attempts to copy your credentials from them to a temporary, to perform ticket-based authentication. There's one check that we could change that would make it work again, but the code still assumes that a "FILE" cache is being used in enough places that I'm uneasy calling that a proper fix. I've opened an upstream ticket to solicit some advice.
Changes proposed upstream, adding current in-progress version of the fixes to krb5-1.11.3-30.el7. We'll probably need to revise them, but in the meantime we can get some testing.
Hi Nalin, I'm not sure if this issue is related but ksu still does not work is the target is root. The scenario below is working on RHEL-6. BTW, the originally reported issue is working. # echo Ariel > /root/.k5login # echo Ariel > /home/Ariel/.k5login # # su - ktest Last login: Wed Nov 13 09:31:01 EST 2013 on pts/0 $ $ kinit Ariel Password for Ariel: $ klist Ticket cache: KEYRING:persistent:1006:1006 Default principal: Ariel Valid starting Expires Service principal 11/13/2013 09:39:36 11/14/2013 09:39:36 krbtgt/ZMRAZ.COM renew until 11/13/2013 09:39:36 $ $ ksu Ariel -e /bin/id Authenticated Ariel Account Ariel: authorization for Ariel for execution of /bin/id successful Changing uid to Ariel (1005) uid=1005(Ariel) gid=1005(Ariel) groups=1005(Ariel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ $ ksu -e /bin/id account root: authorization failed $
The case above was opened as new bug 1030002
It turns out that, contrary to my initial diagnosis, it's actually part of this bug that I missed the first couple of revisions - marking #1030002 as a duplicate of this one.
*** Bug 1030002 has been marked as a duplicate of this bug. ***
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.