Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 154719

Summary: sudo causes incorrect pam_tally attempts
Product: Red Hat Enterprise Linux 3 Reporter: Rob Payne <rpayne>
Component: sudoAssignee: Karel Zak <kzak>
Status: CLOSED DUPLICATE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: dave
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-09 13:16:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Rob Payne 2005-04-13 18:49:12 UTC
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):
sudo-1.6.7p5-1

How reproducible:
Always

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 21:32:30 UTC
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
Password:
 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
Password:
Sorry, try again.
Password:
Sorry, try again.
Password:
Sorry, try again.
sudo: 3 incorrect password attempts
[dave@cheddar dave]$ sudo /sbin/pam_tally
Password:
User dave       (504)   has 3

[dave@cheddar dave]$ rpm -q pam sudo courier-imap
pam-0.75-62
sudo-1.6.7p5-1
courier-imap-3.0.4-1.3ES
[dave@cheddar dave]$ cat /etc/redhat-release
Red Hat Enterprise Linux ES release 3 (Taroon Update 4)

Comment 2 Karel Zak 2005-05-09 13:16:19 UTC

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