Bug 551764

Summary: kpropd fails with /usr/kerberos/sbin/kdb5_util returned a bad exit status
Product: [Fedora] Fedora Reporter: Louis Lagendijk <louis>
Component: krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: nalin
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 1.7-18.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-14 12:07:44 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
This is the strace output of the second (failed) kdb5_util invocation
This is the strace of the first kdb5_util invocation none

Description Louis Lagendijk 2010-01-01 15:52:56 EST
Description of problem:
Kpropd fails to load database pushed from server

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

How reproducible:

Steps to Reproduce:
1.Use kprop from server (Centos 5) to push a daabase to the Fedora 12 client
2.kpropd receives from_master and tries to update db
3.kdb5_util fails with "kdb5_util: File exists" and kpropd fails with /usr/kerberos/sbin/kdb5_util returned a bad exit status (1)
Actual results:

/usr/kerberos/sbin/kdb5_util returned a bad exit status (1) and kpropd terminates

Expected results:
db updated, no errors

Additional info:
Comment 1 Louis Lagendijk 2010-01-02 07:04:32 EST
Forgot to mention that I get the same results when I run kdb5_util manually: a 
kdb5_util load from_master fails: kdb5_util: File exists

An update with 
kdb5_util load -update from_master
Comment 2 Nalin Dahyabhai 2010-01-05 13:44:28 EST
If you create a dummy database on the F12 machine first, does the kprop run initiated on the CentOS box succeed?  (The locking code used for 'load' doesn't quite do the right thing when there isn't a database there already.)
Comment 3 Louis Lagendijk 2010-01-05 16:58:34 EST
No, it does not:

[root@travel krb5kdc]# \rm principal*
[root@travel krb5kdc]# kdb5_util create -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'FAZANT.NET',
master key name 'K/M@FAZANT.NET'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: 
Re-enter KDC database master key to verify: 
[root@travel krb5kdc]# /etc/init.d/kprop restart
Stopping Kerberos 5 Propagation Server:                    [FAILED]
Starting Kerberos 5 Propagation Server:                    [  OK  ]

Run kprop from Centos here....

[root@travel krb5kdc]# /etc/init.d/kprop status
kpropd dead but subsys locked

using kdb5_util load maunually fails ONLY when principal~ and/or principal~.ok exist. If i rm them, kdb5_util succeeds. What do these files do/mean?
Comment 4 Nalin Dahyabhai 2010-01-05 17:38:17 EST
They're the new/temporary principal database and its associated lock file.  After the new database is populated (and the new policy database, too), the set are renamed into place.  Having leftovers from a previous, unsuccessful, attempt hanging around triggers an error somewhere else.
Comment 5 Nalin Dahyabhai 2010-01-05 18:50:38 EST
I've just built krb5-1.7-16.fc13 in koji (http://koji.fedoraproject.org/koji/taskinfo?taskID=1904346) with what I think is the right fix from upstream's development trunk, and it seems to resolve it when I try it here.  If it also resolves it for you, I'll add it to the F12 branch.
Comment 6 Louis Lagendijk 2010-01-06 10:00:36 EST
Sorry, it does not work. kdb5_util leaves all the ~ files, and fails because of their existance the next time. Should kdb5_util remove them? 

I rebuilt the src.rpm on f12, just to be sure I would not run into dependency issues with rawhide
Comment 7 Louis Lagendijk 2010-01-06 17:45:20 EST
I did some more checking, and here is what I found:
cd /var/kerberos/krb5kdc
\rm *~*

so the directory does not contain any ~ files

kdb5_util load from_master
leaves some ~ files:
[root@travel krb5kdc]# ls *~*
principal~.kadm5  principal~.kadm5.lock

A second kdb5_util chokes on the principal~.kadm5 file as shown in the strace output (see attachment)
The second kdb5_util command leaves more ~files:
[root@travel krb5kdc]# ls *~*
principal~  principal~.kadm5  principal~.kadm5.lock  principal~.ok
Comment 8 Louis Lagendijk 2010-01-06 17:47:05 EST
Created attachment 382110 [details]
This is the strace output of the second (failed) kdb5_util invocation
Comment 9 Louis Lagendijk 2010-01-06 17:48:03 EST
Created attachment 382111 [details]
This is the strace of the first kdb5_util invocation
Comment 10 Nalin Dahyabhai 2010-01-06 19:04:02 EST
Okay, that means I missed part of the upstream fix when I pulled it down from trunk, which doesn't have this problem.  Simplest alternative is to pull up the fix from the pending enterprise update.  Please give 1.7-17.fc13 from http://koji.fedoraproject.org/koji/taskinfo?taskID=1906159 a try.
Comment 11 Louis Lagendijk 2010-01-07 15:01:38 EST
This works! Thanks for the help!
Comment 12 Louis Lagendijk 2010-01-07 16:14:37 EST
ok, correction: it works under strace and if selinux is in permissive mode. In enforcing mode it still fails. /var.log/messages says the following:

Jan  7 22:06:18 travel kpropd[1042]: Connection from nest.pheasant
Jan  7 22:06:20 travel kpropd[1042]: /usr/kerberos/sbin/kpropd: /usr/kerberos/sbin/kdb5_util returned a bad exit status (2)
but the audit log does not show any AVCs....
Still continuing the search for what is happening. There is progress, but how to find the selinux issue?
Comment 13 Louis Lagendijk 2010-01-07 17:14:39 EST
False alarm: a restorecon -v in /var/kerberos/krb5kdc solved the issue. I just don't understand why I did not get any AVCs, but who cares
Comment 14 Fedora Update System 2010-01-13 20:21:02 EST
krb5-1.7-18.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Nalin Dahyabhai 2010-01-14 12:07:44 EST
Closing.  Please reopen if this crops up again.