[Pkg-shadow-devel] Bug#443322: Bug#443322: Bug#443322: login: immediate 'Login incorrect' after unknown user name

[Nicolas François]

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