Bug 166422

Summary: pam_loginuid breaking on latest -mm kernel
Product: [Fedora] Fedora Reporter: Reuben Farrelly <reuben-redhatbugzilla>
Component: pamAssignee: Tomas Mraz <tmraz>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: sgrubb, sundaram
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: pam-0.80-7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-08 17:22:51 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:
Attachments:
Description Flags
Patch fixing audit_open failure testing none

Description Reuben Farrelly 2005-08-20 21:04:00 UTC
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 21:13:29 UTC
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 21:15:50 UTC
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 22:01:00 UTC

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 07:35:15 UTC
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 13:18:41 UTC
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 13:21:56 UTC
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 08:40:34 UTC
What about the older kernels which return ECONNREFUSED?
Shouldn't the ECONNREFUSED test stay there too?


Comment 8 Steve Grubb 2005-08-22 10:48:48 UTC
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
compatible.

Comment 9 Reuben Farrelly 2005-09-09 09:25:00 UTC
Fix in rawhide works well, thanks :)