Suddenly segfaulting, even as root

[techcat2]

Hi,

I've been using authenticate-pam for pam authentication with express.js (node 0.10.28) for a few months now without problems, but out of the blue today I just found out it was suddenly segfaulting at every auth attempt, bringing the node app down.

The app itself hasn't (afaik) changed, so I'd guess something must have changed on the server (no idea what, nothing should have changed). Any suggestion about how could I go about debugging this module to find out why it's segfaulting?

The documentation clearly reads that it might segfault when running as non-root, but the issue also happens with the root user.

Regards.

[Rush]

Just checked latest node 0.10 and 0.12 - works for me on openSUSE 13.2

Perhaps try this for debugging: https://github.com/ddopson/node-segfault-handler

Also .. you can try rebuilding node-authenticate-pam with npde-gyp rebuild -d in its directory.

[techcat2]

Ok, thanks.

So, the trace isn't making things a whole of a lot more clear for me other than pointing at: authenticate_pam.node(_Z17doing_auth_threadP9uv_work_s+0xc6)[0x2b7c04d0bf16]
libpam.so.0(_pam_dispatch+0x279)
pam_krb5.so(pam_sm_authenticate+0x6db)
libkrb5.so.3(krb5_get_init_creds_password+0x4f8)

So off to the second option and I'm giving the rebuild a try. It seems to rebuild fine and generates the "authenticate_pam.node", but now when starting the node app it errs with a "Cannot find module 'authenticate-pam'"

Could it be that I'm missing some extra step after rebuilding, maybe?

PS: got it. Still no clue about why it's segfaulting, I'll keep investigating.

[trestletech]

(Thanks for contributing this great library, Damian.)

We're getting a perhaps related error. RHEL 6.4, Node 10.21 running as root. Here's the GDB output:

Program received signal SIGABRT, Aborted. 
0x000000337ca328a5 in raise () from /lib64/libc.so.6 
(gdb) bt 
#0 0x000000337ca328a5 in raise () from /lib64/libc.so.6 
#1 0x000000337ca3400d in abort () from /lib64/libc.so.6 
#2 0x000000337ca707b7 in __libc_message () from /lib64/libc.so.6 
#3 0x000000337ca760e6 in malloc_printerr () from /lib64/libc.so.6 
#4 0x000000337ca78e74 in _int_free () from /lib64/libc.so.6 
#5 0x0000003e0a2034ca in pam_end () from /lib64/libpam.so.0 
#6 0x00007f915d777f07 in doing_auth_thread(uv_work_s*) () from /opt/shiny-server/node_modules/authenticate-pam/build/Release/authenticate_pam.node 
#7 0x00000000006e5810 in worker (arg=<value optimized out>) at ../deps/uv/src/unix/threadpool.c:74 
#8 0x00000000006db1af in uv__thread_start (ctx_v=<value optimized out>) at ../deps/uv/src/uv-common.c:322 
#9 0x000000337ce07851 in start_thread () from /lib64/libpthread.so.0 
#10 0x000000337cae890d in clone () from /lib64/libc.so.6

The relevant PAM profile is:

#%PAM-1.0
auth  requisite pam_succeed_if.so uid >= 500 quiet
auth  sufficient  pam_vas3.so create_homedir get_nonvas_pass try_first_pass
auth  requisite pam_vas3.so echo_return
auth  required  pam_unix.so nodelay use_first_pass

account sufficient  pam_vas3.so
account requisite pam_vas3.so echo_return
account required  pam_unix.so
password  required  pam_deny.so
session required  pam_deny.so

Thanks!

[Rush]

Have you managed to find a solution?

[techcat2]

It fixed itself "automatically" for me. I didn't change anything at all (and as far as I know nothing else was changed on that server) and a couple of weeks later it was working, and has been working nicely since then.

I have no clue about why it was crashing.