Bug 154719

Summary:	sudo causes incorrect pam_tally attempts
Product:	Red Hat Enterprise Linux 3	Reporter:	Rob Payne <rpayne>
Component:	sudo	Assignee:	Karel Zak <kzak>
Status:	CLOSED DUPLICATE	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	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:	---	Target Upstream Version:
Embargoed:

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 ***