Segmentation fault when trying to start kadmind

Joshua Schaeffer jschaeffer0922 at gmail.com
Tue Jul 18 23:49:18 EDT 2017


On 07/18/2017 09:50 AM, Greg Hudson wrote:
> The proximal bug is that master_entry->key_data is an array, bounded by
> master_entry->n_key_data, and this code isn't checking if
> master_entry->n_key_data > 0 before dereferencing the first element.
> You could fix that bug (set *kvno = 1 if n_key_data is 0) and probably
> get kdb5_util stash and kadmind to report an error rather than crash.

Thanks for the suggestion, this has gotten me farther. I changed the code, started from a fresh container, and reran through my steps and I was able to get past the seg fault (See below for results).

> That leaves several mysteries, which I don't have the answer to:
>
> * Why does the master DB entry (K/M) have no key data?

Well, I believe this is the key question. When I run kdb5_util stash I now get this error:

    root at bllkrb501:/usr/local/lib/krb5/plugins/kdb# kdb5_util stash -f /usr/local/etc/krb5kdc/stash
    get_plugin_data_sym(kdb_function_table)
    kdb5_util: Can not fetch master key (error: No such file or directory). while reading master key
    kdb5_util: Warning: proceeding without master key
    Enter KDC database master key:
    kdb5_util: Cannot find master key record in database while getting master key list

But the problem is the record does exist:

    root at bllkrb501:/usr/local/lib/krb5/plugins/kdb# ldapsearch -LLL -D cn=kdc-srv,dc=appendata,dc=net -W -H ldaps://bllldap01.appendata.net -b cn=krbContainer,dc=appendata,dc=net '(krbPrincipalName=K/M*)'
    Enter LDAP Password:
    dn: krbPrincipalName=K/M at APPENDATA.NET,cn=APPENDATA.NET,cn=krbContainer,dc=appendata,dc=net
    krbLoginFailedCount: 0
    krbMaxTicketLife: 36000
    krbMaxRenewableAge: 604800
    krbTicketFlags: 192
    krbPrincipalName: K/M at APPENDATA.NET
    krbPrincipalExpiration: 19700101000000Z
    krbLastPwdChange: 19700101000000Z
    krbExtraData:: ...
    krbExtraData:: ...
    krbExtraData:: ...
    objectClass: krbPrincipal
    objectClass: krbPrincipalAux
    objectClass: krbTicketPolicyAux

So, are you saying that something is missing from this record?

I'm leaning towards it not being an LDAP connection issue or access list problem, because I can destroy the realm successfully and recreate it many times over from the Kerberos server. However, I'm going to look through the LDAP logs when I get a chance tomorrow, just to make sure nothing pops up from the LDAP side.

> * Why isn't the code able to load the shared object from
> /usr/local/lib/krb5/plugins/kdb/kldap?  (It is probably falling back to
> the module in the system directory which is the 1.13.x code, which is
> why it continues to work at all.)

I just created a symlink and this error now goes away. You can see from the command above that all that gets reported now is "get_plugin_data_sym(kdb_function_table)".

    root at bllkrb501:/usr/local/lib/krb5/plugins/kdb# ls -l
    total 408
    -rw-r--r-- 1 root root 366680 Jul 18 20:53 db2.so
    lrwxrwxrwx 1 root root      8 Jul 18 20:59 kldap -> kldap.so
    -rw-r--r-- 1 root root  21008 Jul 18 20:53 kldap.so

I don't know why a symlink wouldn't get created when I installed Kerberos from the package management system. I would think something like this would be included in the post install scripts. Ultimately this seems to fix/change nothing. I'm still seeing my core issue. I just don't get that annoying warning anymore. :/
>
> * Where is that "invalid file descriptor -1 in syscall write()" event
> occurring in the code, and why?  It happens before the master password
> is read, so it's presumably not from the code that writes the stash file.

Currently unsure on this one. Need to do more debugging and research.

>
> * Why didn't kdb5_ldap_util create -s make a stash file?  (Did you
> re-run kdb5_ldap_util create after locally building 1.15.1?  If not, the
> stash file might be in a different place than the 1.15.1 code is looking
> for it.)
I thought the same thing. The first time I compiled the code I used "--sysconfdir=/etc". I couldn't find a stash file anywhere under this directory. When I changed the code and recompiled I just used all the /usr/local/... defaults this time, thinking maybe this time it will just create the stash file under /usr/local/etc instead, but still no luck. After I do a make install I get nothing under that directory.

I've searched my entire system for a file called "stash" (that's what KRB5 creates when you add the -s, right?) and I can't find anything. I guess I need to do more debugging on this too to see why it isn't actually creating the stash file. My assumption is that it isn't being created because of the error above.

Thanks,
Joshua Schaeffer


More information about the Kerberos mailing list