Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
We are authenticating dovecot users via PAM. Our PAM-Setup includes pam_shield. pam_shield uses libgdbm6.
As soon as pam_shield is triggered (meaning it blocks an IP) we get a trap divide error.
Details see below
* What exactly did you do (or not do) that was effective (or
ineffective)?
When removing pam_shield from our PAM-Setup the problem disappears
* What was the outcome of this action?
* What outcome did you expect instead?
Just works.
Journal-Output:
Aug 31 18:02:34 xyz dovecot[2451]: auth: Error: auth-worker: Aborted PASSV request for xyz@xyz.xyz: Worker process died unexpectedly
Aug 31 18:02:34 xyz dovecot[2451]: auth-worker: Fatal: master: service(auth-worker): child 118182 killed with signal 8
Aug 31 18:02:34 xyz kernel: traps: auth[118182] trap divide error ip:7f7366d16f06 sp:7ffc44386580 error:0 in libgdbm.so.6.0.0[7f7366d12000+a000]
PAM-Setup:
auth required pam_abl.so config=/etc/security/pam_abl.conf
auth sufficient pam_mysql.so list-of-options-remoed
auth required pam_shield.so
auth required pam_deny.so
*** End of the template - remove these template lines ***
Hello, I don't know if the problem comes from gdbm or pam_shield yet. The pam_shield package, although orphaned, could be updated. The original pam-shield repository is archived [1], but there seems to be a more recent fork [2]. Could you test with h0tw1r3's 0.9.7 release [3] if the problem persist? If this fixes the problem, then updating pam-shield package would fix this issue. /Nicolas [1] https://github.com/jtniehof/pam_shield [2] https://github.com/h0tw1r3/pam_shield [3] https://github.com/h0tw1r3/pam_shield/releases/tag/0.9.7
Hi, PAM-shield uses a database file that I migrated from debian 10 to debian 12 in one big double upgrade. For testing purposes I deleted that database file, created an empty file instead and the trap divide error disappeared. PAM-shield works fine again as well and has been for three days now. So... problem solved for my case. Is this problem still relevant for libgdbm as we have a trap divide error that should not happen no matter what? Or should I open a ticket at libpam-shield so the problem (and the solution) is documented - even if the package is orphaned? Thanks for your support! Schnitzi
Hello Christopher, Le 2023-09-04 à 04 h 09, Christopher Voglstätter a écrit : It's a good and a bad news at the same time. A good news because you found a working workaround, and a bad news because since a database reset works, it should mean a problem in gdbm itself during some kind of upgrades. I don't know if we can go further with this, but did you keep the old database file? So one could try to reproduce the problem, and if so, forward it upstream. /Nicolas
Hello, Any update on this development? /Nicolas