Bug#482352: Bug#443322: [Pkg-shadow-devel] Bug#443322: Bug#443322: login: immediate 'Login incorrect' after unknown user name
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/msg8.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]
Bug#443322: [Pkg-shadow-devel] Bug#443322: Bug#443322: login: immediate 'Login incorrect' after unknown user name
Quoting Christian Perrier ([EMAIL PROTECTED]): Quoting Dwight Davis ([EMAIL PROTECTED]): Oops!, these lines are indeed different in my config, but they make no difference. The line that is causing this behavior is: auth requisite pam_securetty.so According to the man page this module should have no affect if the username is not recognized. The default for the requisite keyword is to die. Changing the keyword requisite to required, as the man page recommends, causes the normal behavior of login. Yes, I confirm that. I pinged Steve Langasek on IRC to get some more expert advice when it comes at PAM stuff. 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 signature.asc Description: Digital signature
Bug#443322: [Pkg-shadow-devel] Bug#443322: Bug#443322: login: immediate 'Login incorrect' after unknown user name
I'm still not closing this bug, and would prefer to have co-maintainers opinion. I fully agree with your analysis. signature.asc Description: Digital signature
