Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 158212

Summary: PAM auth and crashing apache
Product: Red Hat Satellite 5 Reporter: Jack Neely <jjneely>
Component: ServerAssignee: Adrian Likins <alikins>
Status: CLOSED DUPLICATE QA Contact: Fanny Augustin <fmoquete>
Severity: medium Docs Contact:
Priority: medium    
Version: 370CC: rhn-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-20 18:16:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jack Neely 2005-05-19 16:45:46 UTC
Description of problem:

I'm running Satellite 3.7.0 on AS 4.

I create user accounts with a fake password and then reconfigure the account to
use PAM for our single signon system.  The user receives an email telling them
to use the fake password.  If they attempt to log into the Satellite with the
fake password it correctly denies them access.  However, that apache process
goes up to 100% CPU utilization and no longer functions.  I have to manually log
in a kill that apache process.

Two parts:

* The fake passwrod shouldn't crash apache.  (Wrong passwords do not crash apache.)

* The account creation forms should have a button to select to enable PAM
authentication rather than sending the user a password that is missleading at best.

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

Comment 1 Mihai Ibanescu 2005-05-19 22:05:16 UTC
This is a duplicate.

Comment 2 Adrian Likins 2005-05-20 18:16:50 UTC
More specifically, a duplicate of a currently private internal bug.
Basically, PyPAM is buggy, and there are some pending sat code changes
to fix it that are headed for the next release. 

*** This bug has been marked as a duplicate of 157065 ***

Comment 3 Jack Neely 2005-06-14 18:45:35 UTC
The perl interface to PAM also appears to be buggy.  Although not a constant
problem I can get the web login perl code to also hang up in PAM.

0x006769e7 in error_message ()
   from /lib/
(gdb) bt
#0  0x006769e7 in error_message () from /lib/
#1  0x00733f3d in pam_sm_close_session () from /lib/security/
#2  0x0072ecf7 in pam_sm_authenticate () from /lib/security/
#3  0x00432a7a in _pam_dispatch () from /lib/
#4  0x0043466b in pam_authenticate () from /lib/
#5  0x0045b87f in XS_Authen__PAM_pam_authenticate (my_perl=0x8d2f0f8,
    cv=0x863db58) at PAM.xs:665
#6  0x03db39d2 in Perl_pp_entersub ()
   from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/
#7  0x03d96dbd in Perl_runops_debug ()
   from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/
#8  0x03d41ae6 in Perl_get_cv ()
   from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/
#9  0x03d47e67 in Perl_call_sv ()
   from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/
#10 0x00146c46 in perl_call_handler (sv=0x961a698, r=0x814d088, args=0x0)
    at mod_perl.c:1668
#11 0x001478ae in perl_run_stacked_handlers (hook=0x961a698 "t�\027\b\001",
    r=0x814d088, handlers=0x8869ed0) at mod_perl.c:1381
#12 0x00149d5f in perl_handler (r=0x814d088) at mod_perl.c:904
#13 0x08054b2a in ap_invoke_handler ()
#14 0x0806a0db in process_request_internal ()
#15 0x0806a273 in ap_process_request ()
---Type <return> to continue, or q <return> to quit---
#16 0x0806038b in child_main ()
#17 0x0806073e in make_child ()
#18 0x08061df9 in standalone_main ()
#19 0x08062e77 in main ()