>Number:         9955
>Category:       bin
>Synopsis:       kpasswd init fails when it shouldn't
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 22 10:50:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     William O Ferry
>Release:        <NetBSD-current source date>
>Organization:
>Environment:
	
System: NetBSD slipstream.wofme.com 1.4U NetBSD 1.4U (kernel) #0: Thu Mar 23 22:10:22 PST 2000 root@slipstream.wofme.com:/usr/obj.i386/kernel i386


>Description:
	
	krb4_init() returns a failure (-1) on a system where everything
is set up properly.  The code in krb4_init() considers the initialization
a failure if the result of krb_get_lrealm matches KRB_REALM.  I don't see
why this should be considered a failure, they certainly match in my realm
as I have site.h configured to match my site.
>How-To-Repeat:
	
On a system with KRB4 configured and proper binaries installed:

% passwd -k
passwd: illegal option -- k
usage:
        passwd [-l] [user]
% kpasswd
kpasswd: Can't change password.

>Fix:
	
	I reversed the sense of the strcmp at line 271 of
domestic/usr.bin/passwd/kadm_passwd.c to test for "!= 0" instead of
"== 0" and everything worked properly.

	This certainly could be a misunderstanding on my part, I guess
it's possible that I wasn't supposed to touch KRB_REALM in site.h, and
that this comparison is checking to make sure that the krb.realm file is
configured by the fact that it doesn't match the default value in site.h.
But if this is the case then site.h should have a comment added stating
that the value of KRB_REALM should not be touched, and I'm not sure that
some programs don't just use that value rather than specifically calling
krb_get_lrealm().






>Release-Note:
>Audit-Trail:
>Unformatted:
 Sources suped 4/18 22:15 PDT