Description of problem:

It may be possible for a user to successfully authenticate via PAM while
configuration would suggest a failure.

This will happen if all the following conditions are met:

- the user trying to authenticate exists
- an "auth" module is called from pam_stack
- this module returns PAM_IGNORE for pam_authenticate()
- action is [default=die] -OR- action is [default=bad] and module is at end of
the stack

Version-Release number of selected component (if applicable):

pam-0.77 (apparently also applies to upstream 0.99.4.0)

How reproducible:

It is possible to reproduce this using "pam_debug", although the same problem
was observed using a much more complex configuration using LDAP + pam_ccreds.

Steps to Reproduce:
1. add the following line to /etc/pam.d/system-auth: "auth [default=die]
/lib/security/$ISA/pam_debug auth=ignore"
2. try to login as "root" from console (must use /etc/pam.d/login, GDM won't work)
  
Actual results:

Authentication is successful and root shell is given.

Expected results:

Authentication fails.

Additional info:

This is happening in libpam/pam_dispatch.c because _pam_dispatch_aux() will
return back PAM_IGNORE, and since pam_stack is a "required" (equivalent to
[success=ok new_authtok_reqd=ok ignore=ignore default=bad]) it will be ignored
and authentication successful.

_pam_dispatch_aux() should not return PAM_IGNORE if action is _PAM_ACTION_BAD or
_PAM_ACTION_DIE, but rather PAM_MUST_FAIL_CODE (=PAM_PERM_DENIED).

I am attaching a patch that fixes this behavior.

I'm sorry, but this is not possible to change without upstream acceptance and I
don't agree with the change too. This is not really a bug but a feature of the
stack processing in libpam.

pam_stack is deprecated and that's one of the reasons why.

It should be possible to use jump actions to workaround this issue.

I will consult this bug report with other upstream developers. If it is agreed
to change this behavior upstream we can reconsider it.