On Thu, Nov 09, 2006 at 03:28:27PM -0200, Eduardo Madeira Fleury wrote: > Using RHEL5 Server 10/27 refresh installed with the KS script v0.9 I figured > out that executing run_init always increment the pam_tally2 failure count for > the user in question, which means one day or another the user's account gets > locked, currently this happens after 6 successfull run_init calls. [...] > # pam_tally2 --user tux > # run_init service > Type in the correct password, you should see run_init usage string. > # pam_tally2 --user tux > > ... shows 1 failure. And, if you repeat the run_init command 5 or 6 times the > tux account will be locked and then you must unlock it using
I can reproduce this using the latest milestone and ks script, and turning off enforcing mode doesn't make a difference (so it's not a permission problem). It looks as if run_init is not executing the "session" PAM path. It's configured in /etc/pam.d/run_init to use the system-auth path which would reset the tally count on successful login, but that never happens. To confirm this, I added the line "session requisite pam_deny.so" as the first "session" rule in /etc/pam.d/run_init, and run_init still executes the session (for example, try "run_init date"). (By contrast, adding "auth requisite pam_deny.so" as the first rule makes run_init always fail the authentication as expected.) I think this qualifies as a bug - when you report it, please include the contents of /etc/pam.d/system-auth and /etc/pam.d/run_init. -Klaus -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
