> On Aug 5, 2018, at 12:33 PM, ASV <a...@inhio.net> wrote:
> 
> Here we go:
> 
> (gdb) frame 2
> #2  0x00001fe05dc02bfb in change (auth_context=0x1fe261682080, 
> admin_principal=0x1fe318614860, version=65408, s=8, sa=0x7f7ffffe0968, 
> sa_size=16, in_data=0x7f7ffffe0310) at kpasswdd.c:410
> 410         ret = kadm5_s_chpass_principal_cond (kadm5_handle, principal, 1, 
> tmp);
> (gdb) p kadm5_handle
> $1 = (void *) 0x0

OK, so no need for a debugging version of the libkadm5srv.so library, ...
Passing it a NULL kadm5_handle is expected to segfault.  The kpasswdd
program should not be doing that!

So the question is how the handle ended up being NULL without kpasswdd
bailing out earlier.

The function that creates the handle is kadm5_init_with_password_ctx(),
which after a bit of indirection ends up in kadm5_s_init_with_context():

 99     ret = krb5_parse_name(ctx->context, client_name, &ctx->caller);
100     if (ret == 0)
101         ret = _kadm5_acl_init(ctx);
102     if (ret)
103         kadm5_s_destroy(ctx);
104     else
105         *server_handle = ctx;
106     return 0;

Line 106 of that function is incorrect.  It should be "return ret",
NOT "return 0".  If either krb5_parse_name() or _kadm5_acl_init()
fail, you'll end up with a NULL kadm5 handle, and a success (0)
return code.

Most likely there's some sort of problem with your admin ACL file.
And we need to fix line 106 of "lib/kadm5/init_s.c".

Thanks for the problem report.

-- 
-- 
        Viktor.

Reply via email to