Bug 111036

Summary: Some files in /etc/pam.d/ contain strange variable $ISA
Product: [Retired] Red Hat Linux Reporter: Peter Bieringer <pb>
Component: pamAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: mitr, nedu
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-12-02 20:03:47 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:

Description Peter Bieringer 2003-11-26 16:05:14 UTC
Description of problem:
Some files in /etc/pam.d contain strange variable $ISA, don't know
why, looks like empty (otherwise the modules would not be found).

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

How reproducible:
Always

Steps to Reproduce:
1. # grep  ISA /etc/pam.d/*


Actual Results:  Following files have such variable included

# for f in /etc/pam.d/*; do if grep -q ISA $f; then echo $f; fi; done
/etc/pam.d/authconfig
/etc/pam.d/other
/etc/pam.d/su
/etc/pam.d/system-auth

# grep  ISA /etc/pam.d/*
/etc/pam.d/authconfig:auth       sufficient    
/lib/security/$ISA/pam_rootok.so
/etc/pam.d/authconfig:auth       required      
/lib/security/$ISA/pam_stack.so service=system-auth
/etc/pam.d/authconfig:account    required      
/lib/security/$ISA/pam_permit.so
/etc/pam.d/authconfig:session    required      
/lib/security/$ISA/pam_permit.so
/etc/pam.d/other:auth     required       /lib/security/$ISA/pam_deny.so
/etc/pam.d/other:account  required       /lib/security/$ISA/pam_deny.so
/etc/pam.d/other:password required       /lib/security/$ISA/pam_deny.so
/etc/pam.d/other:session  required       /lib/security/$ISA/pam_deny.so
/etc/pam.d/su:auth       sufficient   /lib/security/$ISA/pam_rootok.so
/etc/pam.d/su:#auth       sufficient   /lib/security/$ISA/pam_wheel.so
trust use_uid
/etc/pam.d/su:auth       required     /lib/security/$ISA/pam_wheel.so
use_uid
/etc/pam.d/su:auth       required      
/lib/security/$ISA/pam_stack.so service=system-auth
/etc/pam.d/su:account    required      
/lib/security/$ISA/pam_stack.so service=system-auth
/etc/pam.d/su:password   required      
/lib/security/$ISA/pam_stack.so service=system-auth
/etc/pam.d/su:session    required      
/lib/security/$ISA/pam_stack.so service=system-auth
/etc/pam.d/su:session    optional       /lib/security/$ISA/pam_xauth.so
/etc/pam.d/system-auth:auth        required     
/lib/security/$ISA/pam_env.so
/etc/pam.d/system-auth:auth        sufficient   
/lib/security/$ISA/pam_unix.so likeauth nullok
/etc/pam.d/system-auth:auth        sufficient   
/lib/security/$ISA/pam_ldap.so use_first_pass
/etc/pam.d/system-auth:auth        required     
/lib/security/$ISA/pam_deny.so
/etc/pam.d/system-auth:account     required     
/lib/security/$ISA/pam_unix.so
/etc/pam.d/system-auth:account     sufficient   
/lib/security/$ISA/pam_ldap.so
/etc/pam.d/system-auth:password    required     
/lib/security/$ISA/pam_cracklib.so retry=3 type=
/etc/pam.d/system-auth:password    sufficient   
/lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
/etc/pam.d/system-auth:password    sufficient   
/lib/security/$ISA/pam_ldap.so use_authtok
/etc/pam.d/system-auth:password    required     
/lib/security/$ISA/pam_deny.so
/etc/pam.d/system-auth:session     required     
/lib/security/$ISA/pam_limits.so
/etc/pam.d/system-auth:session     required     
/lib/security/$ISA/pam_unix.so
/etc/pam.d/system-auth:session     optional     
/lib/security/$ISA/pam_ldap.so

    

Expected Results:  No such variable, like e.g. on RHL 7.3

Additional info:

Perhaps this can be lead to a security issue...perhaps caused by a
build problem?

Comment 1 Nalin Dahyabhai 2003-12-02 20:03:47 UTC
That's known and expected.  The token is available as a placeholder
for paths on systems which support more than one instruction
architecture (as described at
http://www.opengroup.org/pubs/corrigenda/u039f.htm).

A different approach is to remove the path to the module altogether,
and let libpam search its compiled-in default directory.  For now I'm
interested in making sure that both approaches work, and knowing
(quickly) if that changes.  Marking notabug.