Hide Forgot
Description of problem: There is a "cosmetical" change on ksu behaviour after the rebase to krb5-1.13.1-1.el7. ksu now prompts for password even for root user, but then it seems it just ignores it and grants access (like it used to). The change actually is in the password prompting. Is there a reason for it? I found no change if I enter a correct password or nothing. Version-Release number of selected component (if applicable): krb5-1.13.1-1.el7 but al well krb5-1.13.2-3.el7 How reproducible: always Steps to Reproduce: [root@rhel70 ~]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false default_realm = EXAMPLE.COM default_ccache_name = KEYRING:persistent:%{uid} [realms] EXAMPLE.COM = { kdc = kerberos.example.com admin_server = kerberos.example.com } [domain_realm] # .example.com = EXAMPLE.COM # example.com = EXAMPLE.COM [root@rhel70 ~]# [root@rhel70 ~]# ls -la /home/alice/ total 16 drwx------. 2 alice alice 79 Jul 27 18:12 . drwxr-xr-x. 4 root root 29 Jul 27 18:11 .. -rw-------. 1 alice alice 38 Jul 27 18:17 .bash_history -rw-r--r--. 1 alice alice 18 Jan 11 2015 .bash_logout -rw-r--r--. 1 alice alice 193 Jan 11 2015 .bash_profile -rw-r--r--. 1 alice alice 231 Jan 11 2015 .bashrc [root@rhel70 ~]# [root@rhel70 ~]# rpm -q krb5-workstation krb5-workstation-1.13.2-3.el7.x86_64 [root@rhel70 ~]# 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 Could not get a tgt for alice Changing uid to alice (1002) [alice@rhel70 root]$ id uid=1002(alice) gid=1002(alice) groups=1002(alice) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [alice@rhel70 root]$ Note, in the command above no password was entered. Actual results: Password is asked, but access is granted even if not entered. The access was granted for root in the previous version too, the "problem" is that password is asked and then not checked. Expected results: No prompt for password for root. Additional info: Just for completeness. [root@rhel70 ~]# rpm -q krb5-workstation krb5-workstation-1.12.2-14.el7.x86_64 [root@rhel70 ~]# ksu alice Changing uid to alice (1002) [alice@rhel70 root]$ id uid=1002(alice) gid=1002(alice) groups=1002(alice) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [alice@rhel70 root]$ exit exit
In my testing, ksu asks for a password only when it does not have the appropriate credential for a root user. So for instance, in my freeipa installation, if I `kinit admin` and then `ksu`, there is no password prompt, while if I `kdestroy` and then `ksu`, I will get one because there are no credentials available for an appropriate root user (which is the default user to switch to). I also checked this on a fc21 machine (krb5 1.12) and it is the case there as well. Unless I misunderstand, I do not believe this is a bug.
Actually the reported case is about something different. It is about how ksu acts when it is called by root and want to switch to a particular user for which it does not have kerberos ticket. In the old version of kerberos ksu just switched to the destination used without prompting for password (just like legacy su does). The new version asks for password, but then switches to used no matter if the password is correct or not. This can be considered as regression, unless this is a desired feature, but I can not see how it could be useful. Please see the details below: OLD behaviour: [root@rhel70 ~]# rpm -q krb5-workstation krb5-workstation-1.12.2-14.el7.x86_64 [root@rhel70 ~]# kdestroy -A [root@rhel70 ~]# ksu alice Changing uid to alice (1002) [alice@rhel70 root]$ klist Ticket cache: KEYRING:persistent:1002:krb_ccache_u163hk4 Default principal: alice Valid starting Expires Service principal [alice@rhel70 root]$ exit exit [root@rhel70 ~]# klist klist: Credentials cache keyring 'persistent:0:0' not found [root@rhel70 ~]# [root@rhel70 ~]# # no password was asked; ksu acted just like legacy su NEW behaviour: [root@rhel70 ~]# rpm -q krb5-workstation krb5-workstation-1.13.2-9.el7.x86_64 [root@rhel70 ~]# kdestroy -A [root@rhel70 ~]# # 1/ ksu alice: enter wrong password [root@rhel70 ~]# 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: : ksu: Password incorrect Goodbye [root@rhel70 ~]# [root@rhel70 ~]# # 2/ ksu alice: enter kerberos password [root@rhel70 ~]# 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: : Changing uid to alice (1002) [alice@rhel70 root]$ klist klist: No credentials cache found [alice@rhel70 root]$ exit exit [root@rhel70 ~]# klist klist: Credentials cache keyring 'persistent:0:0' not found [root@rhel70 ~]# [root@rhel70 ~]# [root@rhel70 ~]# # 3/ ksu alice: enter nothing, just press enter [root@rhel70 ~]# 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 Could not get a tgt for alice Changing uid to alice (1002) [alice@rhel70 root]$ id uid=1002(alice) gid=1002(alice) groups=1002(alice) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [alice@rhel70 root]$ klist Ticket cache: KEYRING:persistent:1002:krb_ccache_HGdL1tw Default principal: alice Valid starting Expires Service principal [alice@rhel70 root]$ exit exit [root@rhel70 ~]# klist klist: Credentials cache keyring 'persistent:0:0' not found [root@rhel70 ~]#
I see. Thanks for the clarification!
*** Bug 1303734 has been marked as a duplicate of this bug. ***
Thanks Matt!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2591.html