No, no crashes using "kadmin -l". Crashes always using kpasswd from a remote
machine or directly on the KDC itself.
With "it worked well" I was just referring to the fact that "kadmin -l cpw ..."
doesn't work when kpasswdd is down and it doesn't give any error output,
surprisingly. Once the daemon is up again "worked well" hence still no output
but the password was changed.
Unfortunately I don't know why you do not get enough debug.
I've compiled with the right flags. I've tried even to compile manually from
the tar.gz package (./configure ... make) modifying the Makefile prior to
proceed but it fails after a short while:
.....
CC strlwr.lo
CC strsep_copy.lo
CC strupr.lo
CCLD libroken.la
CC libtest_la-strftime.lo
CC libtest_la-strptime.lo
CC libtest_la-snprintf.lo
CC libtest_la-tsearch.lo
CCLD libtest.la
CC snprintf_test-snprintf-test.o
CCLD snprintf-test
snprintf_test-snprintf-test.o: In function `try':
/root/heimdal-7.5.0/lib/roken/snprintf-test.c:53: warning: vsprintf() is often
misused, please use vsnprintf()
./.libs/libroken.so.19.0: undefined reference to `arc4random_stir'
collect2: ld returned 1 exit status
*** Error 1 in lib/roken (Makefile:1123 'snprintf-test': @echo " CCLD "
snprintf-test;/bin/sh ../../libtool --silent --tag=CC --mode=...)
*** Error 1 in lib/roken (Makefile:972 'all')
*** Error 1 in lib (Makefile:589 'all-recursive')
*** Error 1 in /root/heimdal-7.5.0 (Makefile:636 'all-recursive')
I've even tried to run the daemon under ktrace and it just dies at the end as
you can see below but I don't think that's gonna be useful for you.
I'm not a developer so unfortunately the amount of help I can give you is
pretty limited on this. :(
41873 kpasswdd RET read 2819/0xb03
41873 kpasswdd CALL close(6)
41873 kpasswdd RET close 0
41873 kpasswdd CALL kbind(0x7f7fffff7f70,24,0xc5f5073165aed820)
41873 kpasswdd RET kbind 0
41873 kpasswdd CALL kbind(0x7f7fffff7fb0,24,0xc5f5073165aed820)
41873 kpasswdd RET kbind 0
41873 kpasswdd CALL getpid()
41873 kpasswdd RET getpid 41873/0xa391
41873 kpasswdd CALL sendsyslog(0x7f7fffff5f50,62,0<>)
41873 kpasswdd GIO fd -1 wrote 62 bytes
"<38>kpasswdd[41873]: Changing password for [email protected]"
41873 kpasswdd RET sendsyslog 0
41873 kpasswdd CALL kbind(0x7f7fffff8140,24,0xc5f5073165aed820)
41873 kpasswdd RET kbind 0
41873 kpasswdd CALL kbind(0x7f7fffff8290,24,0xc5f5073165aed820)
41873 kpasswdd RET kbind 0
41873 kpasswdd CALL kbind(0x7f7fffff8290,24,0xc5f5073165aed820)
41873 kpasswdd RET kbind 0
41873 kpasswdd PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0xc8 trapno=6
41873 kpasswdd NAMI "kpasswdd.core"
On Fri, 2018-08-03 at 10:59 -0400, Viktor Dukhovni wrote:
> > On Aug 3, 2018, at 5:27 AM, ASV <[email protected]> wrote:
> >
> > Changing password as suggested (kadmin -l cpw ...) works
>
> No crashes, right? Modulo authentication of the user, UDP transport,
> ...
> ultimately "kadmin -l cpw" and "kpasswd" should end up calling the
> same change() function in much the same way.
>
> > After starting back the daemon it worked well.
>
> What does "it worked well" mean?
>
> > I'm using the HDB3 which I believe is part of the package itself
> > (if I properly understood your question).
>
> Yes, thanks.
>
> > This is the output of the procedure on the newly re-compiled
> > heimdal with the CFLAGS="-g -ggdb3 -O0" but doesn't look much
> > different from the previous non-debugging version to me (hopefully
> > I didn't make any mistake).
>
> It looks like something stripped the built binaries, please make sure
> your
> build process does not strip the binaries, and that you're running
> the
> binaries with the debug symbols.
>
> > A snippet of the compilation at the very end of this email.
> >
> > (gdb) bt
> > #0 0x00000ae0709ed5d6 in change () from
> > /usr/local/heimdal/lib/libkadm5srv.so.3.0
> > #1 0x00000ae0709ed55f in kadm5_s_chpass_principal_cond () from
> > /usr/local/heimdal/lib/libkadm5srv.so.3.0
> >
> > #2 0x00000ade6d002bfb in ?? () from
> > /usr/local/heimdal/libexec/kpasswdd
> > #3 0x00000ade6d001b89 in ?? () from
> > /usr/local/heimdal/libexec/kpasswdd
> > #4 0x00000ade6d0017d9 in ?? () from
> > /usr/local/heimdal/libexec/kpasswdd
> > #5 0x00000ade6d001073 in ?? () from
> > /usr/local/heimdal/libexec/kpasswdd
> > #6 0x00000ade6d0009a6 in ?? () from
> > /usr/local/heimdal/libexec/kpasswdd
> > #7 0x0000000000000000 in ?? ()
> > (gdb) x/i $pc
> > 0xae0709ed5d6 <change+102>: cmpl $0x0,0xc8(%r14)
>
> This is a structure member dereference at offset 200 from
> a structure at $r14, which we see below is a NULL pointer:
>
> > (gdb) i reg
> > rax 0x76118487c2646c07 8507726889696390151
> > rbx 0x1 1
> > rcx 0x0 0
> > rdx 0x1 1
> > rsi 0xae13fbbe1a0 11962553196960
> > rdi 0x0 0
> > rbp 0x7f7ffffd58b0 0x7f7ffffd58b0
> > rsp 0x7f7ffffd57a0 0x7f7ffffd57a0
> > r8 0x0 0
> > r9 0xae13fbbe4e0 11962553197792
> > r10 0xae0a1066ab0 11959890504368
> > r11 0xae0a299e000 11959916945408
> > r12 0xae13fbbe1a0 11962553196960
> > r13 0x0 0
> > r14 0x0 0
> > r15 0xae13fbbe4e0 11962553197792
> > rip 0xae0709ed5d6 0xae0709ed5d6 <change+102>
>
> Looking at the code for change(), this seems to be the
> test condition for block:
>
> if (!context->keep_open) {
> ret = context->db->hdb_open(context->context, context->db,
> O_RDWR, 0);
> if(ret)
> return ret;
> }
>
> So somehow the server_handle passed to change() is NULL. Which
> means that the kadm5_handle that kpasswdd passes to
> kadm5_s_chpass_principal_cond() is NULL. The handle is initialized
> via:
>
> ret = kadm5_init_with_password_ctx(context,
> admin,
> NULL,
> KADM5_ADMIN_SERVICE,
> &conf, 0, 0,
> &kadm5_handle);
>
> And failure short-circuits the call to
> kadm5_s_chpass_principal_cond()
> so it is not clear how this could happen. Debugging symbols are
> needed.
>
