On Wed, 2016-04-20 at 11:55 +0200, Jakub Hrozek wrote:
On Tue, Apr 05, 2016 at 02:54:10PM -0400, Simo Sorce wrote:
> On Tue, 2016-04-05 at 12:57 -0400, Simo Sorce wrote:
> > Thanks, IIRC the int-instead of enum use is intentional, I will look
> > at the others.
>
> The last coverity/clang thing is a false positive, but I initialized
> reply to NULL anyway, I expect now it will start complaining of possible
> NULL dereference :-)
>
> Attached find patches that fixes all other issues (hopefully), one of
> them simply dropped an entire function as it turned out I wasn't using
> it.
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
> From 02e259e44631d228e0ec8311392e4a1a1a661b89 Mon Sep 17 00:00:00 2001
> From: Simo Sorce <simo(a)redhat.com>
> Date: Fri, 8 Jan 2016 17:51:06 -0500
> Subject: [PATCH 04/15] Responders: Make the client context more generic
This patch breaks the PAM responder:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x0000000000413512 in accept_fd_handler (ev=0x653a40, fde=0x668970, flags=1,
ptr=0x6604b0) at /sssd/src/responder/common/responder_common.c:478
#2 0x00007f8fe25d5bf3 in epoll_event_loop (tvalp=0x7ffd4e5d41b0, epoll_ev=0x653c80) at
../tevent_epoll.c:728
#3 epoll_event_loop_once (ev=<optimized out>, location=<optimized out>) at
../tevent_epoll.c:926
#4 0x00007f8fe25d4137 in std_event_loop_once (ev=0x653a40, location=0x7f8fe5f88aed
"/sssd/src/util/server.c:689") at ../tevent_standard.c:114
#5 0x00007f8fe25d038d in _tevent_loop_once (ev=ev@entry=0x653a40,
location=location@entry=0x7f8fe5f88aed "/sssd/src/util/server.c:689") at
../tevent.c:533
#6 0x00007f8fe25d052b in tevent_common_loop_wait (ev=0x653a40, location=0x7f8fe5f88aed
"/sssd/src/util/server.c:689") at ../tevent.c:637
#7 0x00007f8fe25d40d7 in std_event_loop_wait (ev=0x653a40, location=0x7f8fe5f88aed
"/sssd/src/util/server.c:689") at ../tevent_standard.c:140
#8 0x00007f8fe5f67b55 in server_loop (main_ctx=0x654e90) at /sssd/src/util/server.c:689
#9 0x0000000000406f57 in main (argc=6, argv=0x7ffd4e5d4598) at
/sssd/src/responder/pam/pamsrv.c:426
(gdb) frame 1
#1 0x0000000000413512 in accept_fd_handler (ev=0x653a40, fde=0x668970, flags=1,
ptr=0x6604b0) at /sssd/src/responder/common/responder_common.c:478
478 ret = accept_ctx->connection_setup(cctx);
(gdb) p accept_ctx
$1 = (struct accept_fd_ctx *) 0x6604b0
(gdb) p accept_ctx->connection_setup
$2 = (connection_setup_t) 0x0
Do you want me to fix this and proceed or will you?
If you already know what's wrong, feel free to fix it, if you have to
spend time analyzing I can do it, should be an easy fix.
The NSS, autofs and IFP responders seem to work fine. I haven't
tested
the others yet.
Ok, sorry for that, I did install SSSD at various times, but was more
concentrated on testing the secrets stuff, and the tests went smoothly,
but I now realize they fake the connection handling.
Simo.
--
Simo Sorce * Red Hat, Inc * New York