Thanks for reporting back, and for solving the problem. So indeed the error message:
[../../pam_oath/pam_oath.c:pam_sm_authenticate(487)] authenticate rc -15 (OATH_FILE_LOCK_ERROR: System error when locking file) last otp Sun Apr 25 17:10:25 4325886 was correct. The other error messages were a bit confusing, so I wonder if something could be improved here. /Simon Thierry CHARLES via OATH Toolkit general discussions <[email protected]> writes: > Ok, I've found the reason while discussing with IA. > > The reason is : there was a lockfile remaining in /etc avoiding > liboath/pam_oath to create a new one. > > # ls /etc/*lock > /etc/shadow.otp.lock > > I removed it, then it worked again ! > > I'll need to make sure this cannot happen anymore > > Thanks for your help > > /Thierry > > > -------- Courriel original -------- > Objet: Re: OATH_INVALID_DIGITS > Date: 2026-03-04 12:50 > De: Thierry CHARLES via OATH Toolkit general discussions > <[email protected]> > À: [email protected] > >> Date: 2026-03-03 22:39 >> De: Simon Josefsson via OATH Toolkit general discussions >> <[email protected]> > >> Could there be some permission problem for /etc/shadow.otp*? > > # ls -l /etc/shadow.otp > -rw------- 1 root root 87 Mar 2 16:55 /etc/shadow.otp > >> Maybe your problems started with the last security fix, see >> https://oath-toolkit.codeberg.page/CVE-2024-47191.html for information >> about the changes we did for that, which could affect this. Could you >> compare pam_oath versions on your working and non-working machines? > > The affected oath version is 2.6.7-3.1+deb12u1 (Debian 12.13) > On an old VM running Debian 11.11 is not affected (oathh 2.6.6-3) > On a VM running Debian 13.2 is not affected (oath 2.6.12-1) > > reading DVE-2024-47191, I guess I'm not concerned because my secrets > file is in /etc and is read-writable only by root > >> Also are you sure of the contents of /etc/shadow.otp? Looks like it is >> picking up some old OTP that doesn't seem consistent with a fresh >> /etc/shadow.otp. >> /Simon > > Yes, I'm sure : i did the "cat" to write my message. This was a > completely new file rewriten (with a easy testing secret "00") to > solve any potential corruption problem. If I change "OATH/T30/6" to > something wrong like "OATH/T30/2" I get another error. So I guess the > file is the one that is read by oath. > > > -- > > During the while, I did a test : I moved the shadow.otp file to user's > directory, changed owner and pam config. now it works well even if the > same OATH_INVALID_DIGITS error is still present : > > > # ls -l /home/thierry/shadow.otp > -rw------- 1 thierry thierry 117 Mar 4 13:43 /home/thierry/shadow.otp > > # cat /home/thierry/shadow.otp > HOTP/T30/6 thierry - 00 0 390212 > 2026-03-04T13:43:14L > > # head /etc/pam.d/su > # TOTP > auth [success=1 default=ignore] pam_succeed_if.so user notingroup > otpauth #saute la ligne suivante si l'utilisateur n'est pas dans > le groupe otpauth > auth required pam_oath.so usersfile=${HOME}/shadow.otp window=5 > digits=6 debug > > # su - thierry > [../../pam_oath/pam_oath.c:parse_cfg(125)] called. > [../../pam_oath/pam_oath.c:parse_cfg(126)] flags 0 argc 4 > [../../pam_oath/pam_oath.c:parse_cfg(128)] > argv[0]=usersfile=${HOME}/shadow.otp > [../../pam_oath/pam_oath.c:parse_cfg(128)] argv[1]=window=5 > [../../pam_oath/pam_oath.c:parse_cfg(128)] argv[2]=digits=6 > [../../pam_oath/pam_oath.c:parse_cfg(128)] argv[3]=debug > [../../pam_oath/pam_oath.c:parse_cfg(129)] debug=1 > [../../pam_oath/pam_oath.c:parse_cfg(130)] alwaysok=0 > [../../pam_oath/pam_oath.c:parse_cfg(131)] try_first_pass=0 > [../../pam_oath/pam_oath.c:parse_cfg(132)] use_first_pass=0 > [../../pam_oath/pam_oath.c:parse_cfg(133)] usersfile=${HOME}/shadow.otp > [../../pam_oath/pam_oath.c:parse_cfg(134)] digits=6 > [../../pam_oath/pam_oath.c:parse_cfg(135)] window=5 > [../../pam_oath/pam_oath.c:pam_sm_authenticate(295)] get user > returned: thierry > [../../pam_oath/pam_oath.c:pam_sm_authenticate(303)] usersfile is > /home/thierry/shadow.otp (id 1000/1000) > [../../pam_oath/pam_oath.c:pam_sm_authenticate(321)] Successfully > dropped effective id to 1000/1000 > [../../pam_oath/pam_oath.c:pam_sm_authenticate(332)] authenticate > first pass rc -2 (OATH_INVALID_DIGITS: Unsupported number of OTP > digits) last otp Sun Jul 31 09:02:24 3092208 > > One-time password (OATH) for `thierry': > [../../pam_oath/pam_oath.c:pam_sm_authenticate(415)] conv returned: > 390212 > [../../pam_oath/pam_oath.c:pam_sm_authenticate(479)] OTP: 390212 > [../../pam_oath/pam_oath.c:pam_sm_authenticate(487)] authenticate rc 0 > (OATH_OK: Successful return) last otp Wed Jan 2 11:03:13 4362684 > > [../../pam_oath/pam_oath.c:pam_sm_authenticate(515)] Successfully > restored effective id to 0/0 > [../../pam_oath/pam_oath.c:pam_sm_authenticate(527)] done. [Success] > > > ==> so the bug only happens when the secrets file is in /etc ! and the > real error is the locking error > > [../../pam_oath/pam_oath.c:pam_sm_authenticate(303)] usersfile is > /etc/shadow.otp (id 0/0) > [../../pam_oath/pam_oath.c:pam_sm_authenticate(332)] authenticate > first pass rc -2 (OATH_INVALID_DIGITS: Unsupported number of OTP > digits) last otp Wed Aug 20 17:04:32 3429642 > > One-time password (OATH) for `thierry': > [../../pam_oath/pam_oath.c:pam_sm_authenticate(415)] conv returned: > 136424 > [../../pam_oath/pam_oath.c:pam_sm_authenticate(479)] OTP: 136424 > [../../pam_oath/pam_oath.c:pam_sm_authenticate(487)] authenticate rc > -15 (OATH_FILE_LOCK_ERROR: System error when locking file) last otp > Mon Aug 14 04:22:25 3972856 > > What could cause this locking error ? > > /Thierry > > > > >
signature.asc
Description: PGP signature
