On Mon, Mar 02, 2009 at 11:09:30AM +0100, Mark Phalan wrote: > > On Fri, 2009-02-27 at 13:13 -0600, Will Fiveash wrote: > > On Fri, Feb 27, 2009 at 10:09:09AM +0100, Mark Phalan wrote: > > > > > > On Thu, 2009-02-26 at 12:00 -0800, Ben Rockwood wrote: > > > > Truss posted here: > > > > > > > > http://www.cuddletech.com/rpcsec-truss.txt > > > > > > Looks like Shawn figured out your problem. You can see the same issue in > > > the truss (just look for krb5_set_error_message()). > > > > > > There probably should be some logic to re-create the directory structure > > > if it isn't there. Kerberos is just too brittle in this respect. I've > > > seen this problem over and over again :( > > > > Maybe. The question is what paths should krb be responsible for > > recreating? Do other native services do this? > > I probably agree with you that directories created by the package system > should be left under the control of the package system. It begs the > question though - why are these directories necessary? why not have a > flatter directory structure and put the replay caches directly > into /var/krb5 ? Perhaps there's a good reason I don't know about. > > > A more fundamental > > problem is that things are being done by root users (or buggy root > > programs) that violate Solaris system integrity. In regards to > > /var/krb5/rcache disappearance I'm betting that people are > > doing 'rm -rf *' in /var/krb5 to clear out the principal DB and lock > > files instead of the recommended 'kdb5_util destroy' which would leave > > the rcache dir in place. > > Unfortunately 'kdb5_util destroy' only works reliably if you have the > same krb5.conf as was used to create the kdb in the first place (well at > least the original realm must be the same).
Not sure what you mean, aren't there command line flags to specify the realm on so on? In fact I removed both krb5.conf and kdc.conf and ran kdb5_util -r MY.REALM destroy and it worked leaving the rcache dir intact. I do believe there is a bug related to this though in the case the master key stash file is removed then kdb5_util destroy will exit with an error. This has been fixed in MITKC 1.7 so we'll also get that fix eventually. > 'kdcmgr' is relatively new and NV only so I can imagine that people > when faced with 'kdb5_util' failing due to configuration change they > don't have much choice but to manually try to delete the kdb and > related files. I hope that is not the case. Sun has never supported using 'rm -rf *' in /var/krb5 (or that was documented that was a mistake). -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/
