On, Thursday 06 July 2006 01:04 Dan Nicholson wrote: > I checked, and I get the same problem. I do put LOGIN_RETRIES in > /etc/login.defs. If I input the successful password on the last > attempt, it still bombs just as you say. Thanks for the check.
> Does this imply that pam_tally doesn't work as advertised? It looks > like login is still using the default of 3 since you put deny=20 in > the pam conf file. This doesn't. "deny" in pam_tally argument list and LOGIN_RETRIES aren't the same things according to shadow source code logic (as I understand it). "deny" value determines the number of unsuccessful _tries_ after which the user will always have "Login incorrect", while LOGIN_RETRIES determines the number of unsuccessful _logins_ after which "login" terminates. In the case of "deny" "unsuccessful tries" haven't to follow one after another. The number of unsuccessful tries differs for different users and it's stored in /var/log/faillog so that every user in a system has "one's own" unsuccessful tries number called "tally" in the terms of pam_tally PAM module. On the other hand, LOGIN_RETRIES value is the number of unsuccessful attempts (possibly of different users) to login after which "login" program terminates. For example, when "login" started by agetty from /etc/inittab is terminated init starts another agetty process which in its turn starts login again so that a user just sees a new login prompt and possibly doesn't even know that the previous login has terminated and what he/she sees is another process. It may be the reason why you wonder why login terminates after 3 tries while the PAM module has 20 as the limit for the number of unsuccessful tries. > Thanks for the effort. Great thank _you and the whole LFS team_ for the only _real_ linux distro :) I'm happy to be able to help you and the people who create/use linux. > I'm not sure it's critical enough to put in the book just yet. I agree. The absence of unnecessary patches is one of the reasons inducing me to install and use LFS rather than another distribution. > However, it would be great if you could submit it to lfs-patches. I'm sorry but can you tell me please HOW I can do it? Should I just send a e-mail to lfs-patches with the bug description and the patch attached or are there other rules for submitting patches? For example should the bug description be long or brief (if it should be at all)? > Even better would be if you submitted it upstream to > the author. He is usually very receptive of patches as long as there > described well. It doesn't look like any such fix is in there now. I had tried that before posting to blfs-support :( Unfortunatelly, I use a common free mail server (www.mail.ru) and it "has been used for a lot of spam email. As such, it has been blacklisted" so I'm unable to send something to the shadow mailing list though I personally do never send spam. > If you prefer, I can submit it since I'm already subscribed. Submit it please as I'm not able to :( P.S. I've just seen the discussion on this thread. I tried to explain in this letter why login.c uses both LOGIN_RETRIES and "deny". Of course, the bug isn't in this "ambivalent" behavior. -- Nothing but perfection pv -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
