Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 154719 - sudo causes incorrect pam_tally attempts
sudo causes incorrect pam_tally attempts
Status: CLOSED DUPLICATE of bug 144893
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sudo (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-04-13 14:49 EDT by Rob Payne
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-09 09:16:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rob Payne 2005-04-13 14:49:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 (CK-Disanet)

Description of problem:
If pam_tally is configured to limit logins when there are too many failed login
attempts, sudo causes this limit to be incorrectly reached.  Initial requests by
sudo for a password (first time that sudo runs, each time that it runs after the
previous authentication has expired) cause the pam_tally counter to increase by
one, whether or not the password was correctly entered.  Correctly entering the
password to sudo does not reset the counter.  Correctly logging in (via ssh or
on the system) correctly resets the counter as long as the tally has not reached
the limit.

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

How reproducible:

Steps to Reproduce:
1. Configure /etc/pam.d/system auth to include the following two lines in
addition to the default configuration:
auth        required      pam_tally.so onerr=fail no_magic_root
account     required      pam_tally.so per_user deny=3 no_magic_root reset

2. sudo pam_tally --reset (reseting the tally list prior to testing)
3. sudo -k
4. sudo w (entering the password, when it is requested)
5. sudo pam_tally (listing the current tally list)

Actual Results:  pam_tally shows a count of 1 for the user that ran sudo.  repeating steps 3-5
shows an increasing pam count.  Once the tally reaches the limit, that user will
be unable to login, and the tally will have to be reset.

Expected Results:  pam_tally should show no output (tally was just reset to zero for all users)

Additional info:
Comment 1 Dave Fogarty 2005-04-19 17:32:30 EDT
I'm having a similar experience, however mine differs some:

1. Successful logins are NOT incrementing PAM's counter.
2. Once failures occur, successes are NOT resetting PAM's counter.

I'm seeing the same problem with IMAP

[dave@cheddar dave]$ sudo /sbin/pam_tally --reset
User dave       (504)   had 3
[dave@cheddar dave]$ sudo /sbin/pam_tally
[dave@cheddar dave]$ sudo -k
[dave@cheddar dave]$ sudo w
 14:22:36  up 55 days,  1:47, 12 users,  load average: 0.04, 0.03, 0.01
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
[dave@cheddar dave]$ sudo /sbin/pam_tally
[dave@cheddar dave]$ sudo -k
[dave@cheddar dave]$ sudo w
Sorry, try again.
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts
[dave@cheddar dave]$ sudo /sbin/pam_tally
User dave       (504)   has 3

[dave@cheddar dave]$ rpm -q pam sudo courier-imap
[dave@cheddar dave]$ cat /etc/redhat-release
Red Hat Enterprise Linux ES release 3 (Taroon Update 4)
Comment 2 Karel Zak 2005-05-09 09:16:19 EDT

*** This bug has been marked as a duplicate of 144893 ***

Note You need to log in before you can comment on or make changes to this bug.