Bug 1247261
| Summary: | ksu asks for password even if called by root | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Patrik Kis <pkis> |
| Component: | krb5 | Assignee: | Robbie Harwood <rharwood> |
| Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | atolani, dpal, pkis, rharwood |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 20:22:43 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1303734 | ||
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 |
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