Bug 491470 - pam_tally2 and sudo issue
pam_tally2 and sudo issue
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-21 09:50 EDT by Dominick Grift
Modified: 2010-05-05 11:09 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-23 08:20:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dominick Grift 2009-03-21 09:50:32 EDT
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):
pam-1.0.91-1.fc11.x86_64

How reproducible:
#%PAM-1.0
# 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 08:09:58 EDT
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 08:20:01 EDT
Whoops yes that seems to make all the difference. Sorry for any inconvenience caused.
Comment 3 fruiz 2010-05-05 09:51:11 EDT
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 10:22:57 EDT
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 11:09:50 EDT
Great explanation!

Thanks in advance! :-)

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