Bug 1247261 - ksu asks for password even if called by root
ksu asks for password even if called by root
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5 (Show other bugs)
7.1
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Robbie Harwood
Patrik Kis
:
: 1303734 (view as bug list)
Depends On:
Blocks: 1303734
  Show dependency treegraph
 
Reported: 2015-07-27 12:28 EDT by Patrik Kis
Modified: 2016-11-03 16:22 EDT (History)
4 users (show)

See Also:
Fixed In Version: krb5-1.14.1-11.el7
Doc Type: Bug Fix
Doc Text:
Cause: Overly conservative fix for a crash in ksu Consequence: ksu would always prompt for password when run as root Fix: Don't do that Result: ksu only prompts for password as root when -n is supplied in accordance with man page.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 16:22:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrik Kis 2015-07-27 12:28:32 EDT
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@EXAMPLE.COM: : 
No password given
Could not get a tgt for alice@EXAMPLE.COM 
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
Comment 4 Robbie Harwood 2015-09-09 17:59:33 EDT
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.
Comment 5 Patrik Kis 2015-09-10 03:27:39 EDT
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@EXAMPLE.COM

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@EXAMPLE.COM: : 
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@EXAMPLE.COM: : 
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@EXAMPLE.COM: : 
No password given
Could not get a tgt for alice@EXAMPLE.COM 
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@EXAMPLE.COM

Valid starting       Expires              Service principal
[alice@rhel70 root]$ exit
exit
[root@rhel70 ~]# klist 
klist: Credentials cache keyring 'persistent:0:0' not found
[root@rhel70 ~]#
Comment 6 Robbie Harwood 2015-09-10 14:12:24 EDT
I see.  Thanks for the clarification!
Comment 9 Robbie Harwood 2016-02-08 15:01:00 EST
*** Bug 1303734 has been marked as a duplicate of this bug. ***
Comment 12 Robbie Harwood 2016-04-28 17:46:44 EDT
Thanks Matt!
Comment 16 errata-xmlrpc 2016-11-03 16:22:43 EDT
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

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