Bug 166422 - pam_loginuid breaking on latest -mm kernel
pam_loginuid breaking on latest -mm kernel
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Depends On:
  Show dependency treegraph
Reported: 2005-08-20 17:04 EDT by Reuben Farrelly
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: pam-0.80-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-08 13:22:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch fixing audit_open failure testing (670 bytes, patch)
2005-08-21 09:18 EDT, Steve Grubb
no flags Details | Diff

  None (edit)
Description Reuben Farrelly 2005-08-20 17:04:00 EDT
After upgrading on a test box from 2.6.13-rc5-mm1 to 2.6.13-rc6-mm1, I am unable
to log in.  After some testing I determined that this was because I did not have
auditing enabled in my kernel .config.  pam_loginuid was not allowing anything
to log in, and instead failing with a message logged in /var/log/secure:

"PAM audit_open() failed: Protocol not supported"

My guess is that the method used to detect the presence of auditing in the
kernel is not robust enough on all kernels.  Thinking particularly with regards
to the pam-0.79-loginuid-req-audit.patch patch which was put in recently..

Note that this bug is NOT a direct duplicate of
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159974 because that bug was
resolved succesfully - this one is new to 2.6.13-rc6-mm1.
Comment 1 Rahul Sundaram 2005-08-20 17:13:29 EDT
Thank you for the report. However it seems better for me to file such a bug
report after the changes have hit mainline kernel and when it ends up in rawhide
development tree rather than a change in -mm kernel which may not even make it
into the mainline kernel and one which isnt even shipped by Fedora at this
point. If you want you can consider posting to the linux kernel mailing list
cc'ing Andrew Morton or file it bugzilla.kernel.org instead

Comment 2 Reuben Farrelly 2005-08-20 17:15:50 EDT
I have already posted to the LKML and Andrew Morton - and the maintainer of the
audit subsystem in the kernel said that this is definitely a userspace problem...
Comment 3 Rahul Sundaram 2005-08-20 18:01:00 EDT

Would it better to post to pam mailing list instead?. Here is my line of
thinking.    This is either a kernel bug (which you have confirmed it is not) or
a upstream pam bug for a component (kernel-mm tree) which isnt shipped as part
of Fedora. It might be better to wait still the kernel changes hit rawhide
before filing it in here I am passing on the final decision to the Fedora Pam
maintainer. He might want to be more proactive about such changes. 
Comment 4 David Woodhouse 2005-08-21 03:35:15 EDT
The kernel changes in the -mm kernel are going in to RHEL4 U2.
For a start, we shouldn't be shipping pam configurations which require
pam_loginuid by default. Auditing is an esoteric requirement which most users
won't want.

Steve Grubb has shown me a patch which works around the configuration error --
by checking for errno==EPROTONOSUPPORT after audit_open() and assuming this
means that auditing isn't enabled in the kernel.
Comment 5 Steve Grubb 2005-08-21 09:18:41 EDT
Created attachment 117952 [details]
Patch fixing audit_open failure testing

I looked at the syscalls made in audit_open and compared with what is being
checked in _pam_auditlog(). We need to update the errno values being checked -
the syscalls have changed since the pam patch was originally created. The
attached patch should solve the problem. I would suggest putting this out for
test in FC4. rawhide could be rolled out anytime.
Comment 6 Steve Grubb 2005-08-21 09:21:56 EDT
Note, audit_open failure has nothing to do with loginuid. The problem is in the
handling of audit_open's errno's after a failure. According to CAPP, we have to
deny login if we are unable to audit logins. We make some narrow exceptions so
that people with custom kernels can still log in.
Comment 7 Tomas Mraz 2005-08-22 04:40:34 EDT
What about the older kernels which return ECONNREFUSED?
Shouldn't the ECONNREFUSED test stay there too?
Comment 8 Steve Grubb 2005-08-22 06:48:48 EDT
I don't think the kernel should return ECONNREFUSED for a socket() call. The man
page doesn't show it as a valid return code. The other call that is made in
audit_open is fnctl(). It should not return that errno either. 

Most of the older kernel succeeded in calling audit_open and we actually trapped
the error whan pam eventually called the sendto() that is inside the
audit_send_user_message() call. So, I think this change would be backwards
Comment 9 Reuben Farrelly 2005-09-09 05:25:00 EDT
Fix in rawhide works well, thanks :)

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