Bug 176970 - passwd always reports successful kerberos5 update, even on fail
Summary: passwd always reports successful kerberos5 update, even on fail
Alias: None
Product: Fedora
Classification: Fedora
Component: pam_krb5   
(Show other bugs)
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-04 21:19 UTC by Paul Jakma
Modified: 2008-02-13 02:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-13 02:58:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Paul Jakma 2006-01-04 21:19:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050923 Galeon/2.0.0

Description of problem:
passwd always seems to indicate that kerberosv5 password is updated, even when it has failed, e.g. due to password reuse.

The native kerberos 'kpasswd' correctly reports to user whether password was updated successfully or not.

$ passwd
Changing password for user foo.
Kerberos 5 Password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.

But in the kadmin logs:

kadmind[3102](Notice): chpw request from 192.
168.0.3 for foo@DOMAIN: Cannot reuse password

kpasswd correctly reports "password change rejected".

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. passwd
2. enter correct current password
3. try enter a password which is within the history/dont-reuse list for the principal concerned.


Actual Results:  passwd reported a succesful password change, even though the change never ocurred.

Expected Results:  It should have reported a failure, just as kpasswd does.

Additional info:

It's a bit of a security issue.

Common practice on password resets can be to assign the user a new password, sometimes communicated via less-than-secure channels (telephone, email, or such). To minimise risk, the user must change the password ASAP. This window of risk is lengthened if the user believes they successfully changed their password.

Comment 1 Tomas Mraz 2006-01-04 22:58:10 UTC
Are there any messages in /var/log/secure and /var/log/messages on the client
machine? Please post them if yes. Also attach /etc/pam.d/system-auth contents here.

Passwd uses pam_krb5 when changing Kerberos passwords -> reassigning.

Comment 2 Paul Jakma 2006-01-05 10:34:29 UTC
This is the messages entry for passwd:

passwd[26324]: pam_krb5[26324]: password changed for foo@DOMAIN

There isn't anything of note in secure.

This is system-auth:

# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_krb5.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so broken_shadow
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     [default=bad success=ok user_unknown=ignore]
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5
password    sufficient    /lib/security/$ISA/pam_krb5.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_krb5.so

Comment 3 Tomas Mraz 2006-01-05 11:00:22 UTC
Then it is a clearly pam_krb5 problem - it shouldn't report password changed
when it actually wasn't changed.

Comment 4 Matthew Miller 2006-07-10 22:38:35 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 5 petrosyan 2008-02-13 02:58:36 UTC
Fedora Core 3 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

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