Package: krb5-admin-server
Version: 1.4.4-7etch1
Hi all --
I have a distributed system with a few servers and several
clients, using Kerboros for user authentication and LDAP for
accounts. All servers are Debian "etch", and the clients are
a mix of "etch" and "sarge".
The problem described here may not occur with all clients,
but does occur with at least one client of each of the two
types.
The symptoms are:
A user on a client invokes "kpasswd" or "kpasswd <username>" to
change their password. Kpasswd prompts for their existing
password, accepts the input, then prompts twice for the new password.
It then appears to hang.
Coincident with the hang, kadmind on the server segfaults,
logging the following in /var/log/messages: ("shadrach" is
the server hostname).
> Jun 13 14:16:11 shadrach kernel: kadmind[31779]: segfault at ffffffffd653bbc0
> rip 00002b5fd63745d0 rsp 00007fffd52f7f58 error 4
The kpasswd process reports a time-out:
> kpasswd: Connection timed out changing password
.. and the user password is not changed.
The location of the segfault appears to vary, an immediate second
attempt got a slightly different log message:
> Jun 13 14:18:38 shadrach kernel: kadmind[1358]: segfault at 0000000020035bc0
> rip 00002ac21fe6e5d0 rsp 00007fff8b7fe468 error 4
Issuing /etc/init.d/krb5-admin-server restarts the daemon with
no apparent additional errors.
Behavior is not 100% consistent, I am sure I have seen
instances where a convenience script named "passwd", which just
wraps a call to "exec kpasswd $(whoami)", did not crash the kadmind,
but I am unable to reproduce this desirable behavior just now,
re-running the identical script is crashing the server's kadmind.
I have never seen a direct call to kpasswd fail to crash the
kadmind, but may have always done those second in the testing
sequence.
The bad behavior is correlated with a high frequency of
password changes for a particular principal (one every 60
300 seconds or so). The initial pathology involved a user
whose (new) account was misconfigured, and whose password
was reset within a few minutes of the initial Kerberos principal
creation to facilitate account configuration testing (directly
via kadmin), and then re-reset by the user once the account
configuration was corrected, using kpasswd. This kpasswd operation
crashed the kadmin daemon.
Subsequent experiments on other accounts may have worked
initially, and then begun to fail, consistent with the difficulty
being triggered by multiple password changes within a
few-minute window. Since I have just done this testing, I cannot
immediately test this.
Kernels are stock Debian. Server is 2.6.18-4-amd64,
representative client is 2.6.18-4-k7, libc is 2.3.6.ds1-13
on client and server.
-- A.
--
Dr. Andrew C. E. Reid, Guest Researcher
Center for Theoretical and Computational Materials Science
National Institute of Standards and Technology, Mail Stop 8910
Gaithersburg MD 20899 USA
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
