Bug 491470 - pam_tally2 and sudo issue
Summary: pam_tally2 and sudo issue
Alias: None
Product: Fedora
Classification: Fedora
Component: pam
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-03-21 13:50 UTC by Dominick Grift
Modified: 2010-05-05 15:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-03-23 12:20:01 UTC
Type: ---

Attachments (Terms of Use)

Description Dominick Grift 2009-03-21 13:50:32 UTC
Description of problem:
When i use this: auth        required	  pam_tally2.so deny=5 onerr=fail, then pam_tally2 counts a failed login attempt each time i (successfully) run sudo.

When i use: auth        required	  pam_tally2.so deny=5 onerr=fail magic_root, then pam_tally2 does not count anything any more (not even failed login attempts by unprivileged users)

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

How reproducible:
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required	  pam_env.so
# auth        sufficient    pam_unix.so nullok try_first_pass
auth        required    pam_unix.so nullok try_first_pass
# auth        requisite     pam_succeed_if.so uid >= 500 quiet
# auth        required      pam_deny.so
# auth        required      /lib64/security/pam_tally.so onerr=fail deny=5 unlock_time=180 even_deny_root_account
auth        required	  pam_tally2.so deny=5 onerr=fail magic_root

account     required	  pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required	  pam_permit.so
# account     required      /lib64/security/pam_tally.so
account     required     pam_tally2.so

# password    requisite     pam_cracklib.so try_first_pass retry=3
password    requisite     pam_passwdqc.so min=disabled,disabled,16,12,8
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional	  pam_keyinit.so revoke
session     required	  pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required	  pam_unix.so

then run: sudo sh
and watch you tally go up in: pam_tally --username ($name)

Expected results:

Additional info:

Comment 1 Tomas Mraz 2009-03-23 12:09:58 UTC
Does it help if you move the 'account required     pam_tally2.so' line right after the pam_unix account line?

Comment 2 Dominick Grift 2009-03-23 12:20:01 UTC
Whoops yes that seems to make all the difference. Sorry for any inconvenience caused.

Comment 3 fruiz 2010-05-05 13:51:11 UTC
So, what is the "real" purpose of magic_root?

If I use "magic_root", failed logins doest count!!

Thanks in advance!

Comment 4 Tomas Mraz 2010-05-05 14:22:57 UTC
It's possible that sudo calls pam with the real uid == 0. In that case it is not possible to use the magic_root option. su should call id with the real uid of the calling user and there it makes sense because su <user> from root account could reset the tally without this option it is also possible to skip over the pam_tally2 with pam_succeed_if though.

But generally using this option is not needed.

Comment 5 fruiz 2010-05-05 15:09:50 UTC
Great explanation!

Thanks in advance! :-)

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