forcemerge 482352 443322 thanks On Sun, Oct 21, 2007 at 01:00:27PM +0200, Christian Perrier wrote: > > A discussion happened on IRC about this: > > 09:38 <vorlon> do you know if that's a recent change in the behavior of > pam_securetty? > 09:38 <vorlon> or is it just a recent change in the contents of > /etc/pam.d/login? > 09:39 <vorlon> I don't like the idea of being able to brute force usernames > via login, however unlikely this is > --- Log closed dim oct 21 09:44:35 2007 > --- Log opened dim oct 21 09:44:48 2007 > 09:44 <vorlon> anyway, the advantage of using requisite for pam_securetty is > that if it's *not* a secure tty, the user has no opportunity to type the root > password at all > 09:44 <vorlon> but apparently there are side effects that don't belong > --- Log closed dim oct 21 09:50:35 2007 > --- Log opened dim oct 21 12:19:42 2007 > 12:19 <bubulle> I don't know if it's a recent change in pam_securetty > 12:19 <bubulle> not a change in /etc/pam.d/login for sure
pam_securetty changed. Now it reports a failure when the user is not known. As the pam_securetty module is a requisite module, the processing of pam modules stop immediately, and no delay are used because the delay is set by pam_unix. This could be fixed in different ways: * change pam_securetty. I asked on https://www.redhat.com/archives/pam-list/2008-June/msg00008.html Thorsten Kukuk (PAM's upstream disagre with my conclusions) * revert the 463_login_delay_obeys_to_PAM Debian patch. Replace it with some documentation that some PAM module may lead to different delays (pam_unix request a delay > 2s) * Call the pam_faildelay module before pam_securetty. (NOTE: pam_faildelay uses the FAIL_DELAY variable from login.defs, which was removed by 463_login_delay_obeys_to_PAM) I will try to get some clarifications from Thorsten. Otherwise, I will reintroduce the delay by disabling 463_login_delay_obeys_to_PAM. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
