Hi Steve, On Sat, Aug 23, 2008 at 10:30:59PM -0700, [EMAIL PROTECTED] wrote: > I just upgraded one of my sid machines that had a modified /etc/pam.d/login, > and was quite surprised to see the conffile prompt from this change, > specifically because of the use of pam_faildelay. > > Did you consider doing this instead for pam_securetty?: > > auth [success=ok user_unknown=ignore default=die] pam_securetty.so
I did not added this because in case of an insecure TTY, if root enters his name with a typo, she will be prompted for a password. (That was my true in my last try: the user is checked before the TTY) There are in fact two contradicting requests on insecure TTYs * if the user is unknown, the password prompt should not be displayed (it might be a typo for root) * the password prompt should always be displayed to avoid giving an indication that the user does not exist. I'm not sure which one is the most critical. > Not sure if that should be considered any better, but it avoids needing to > add another module to the stack. (One which isn't very well documented, if > I do say so myself!) The additional pam_faildelay module replaces a call to pam_fail_delay() which was removed from login (this was done to avoid hardcoding a delay in login (it was in fact in login.defs), which was disturbing for user willing to reduce the delay in login.defs, or to remove the delay by adding nodelay to pam_unix). Would it be better to call pam_faildelay only in case of a pam_securetty failure, and otherwise let pam_unix set the delay? -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
