Sample pam.d/rlogin:
#(bunch of irrelevant stuff deleted) #The following line should always fail, #thus making rlogin auth always fail...right? auth requisite /lib/security/pam_deny.so
account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth
Sample pam.d/system-auth:
#(stock RH8 system-auth file) #You would think the following 3 lines would not get evaluated, #since there was no "auth required pam_stack.so service=system-auth" #in pam.d/rlogin, right? auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok auth required /lib/security/pam_deny.so
#if auth failed in the pam.d/rlogin file, #then none of the rest of this should matter, right? account required /lib/security/pam_unix.so
password required /lib/security/pam_cracklib.so retry=3 type=
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow nis
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so
Yet when I try to rlogin to the host with these settings, I get the following in the /var/log/messages file:
Apr 9 16:15:38 hostfoo rlogind[15198]: PAM authentication failed for in.rlogind
Apr 9 16:15:43 hostfoo login(pam_unix)[15199]: session opened for user johnt by (uid=0)
Apr 9 16:15:43 hostfoo login -- johnt[15199]: LOGIN ON pts/11 BY johnt FROM hostbar
And indeed I can log in after giving the login process my passwd, because even though I failed the auth section in pam.d/rlogin, I succeeded in the auth section of pam.d/system-auth.
###
Now if I set things up like this:
Sample pam.d/rlogin:
#(Stock RH8 pam.d/rlogin file, #except for commented out pam_stack line. #Since pam_rhosts_auth is "sufficient", #the missing pam_stack line shouldn't be a problem, right?) auth required /lib/security/pam_deny.so auth required /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_rhosts_auth.so #auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth
Sample pam.d/system-auth:
#(stock RH8 system-auth file, #except for commented out next 2 lines, #leaving the fall-through pam_deny bare.) #auth required /lib/security/pam_env.so #auth sufficient /lib/security/pam_unix.so likeauth nullok auth required /lib/security/pam_deny.so
#if auth failed in the pam.d/rlogin file, #then none of the rest of this should matter, right? account required /lib/security/pam_unix.so
password required /lib/security/pam_cracklib.so retry=3 type=
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow nis
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so
Which results in the following /var/log/messages entries:
Apr 9 16:32:27 hostfoo login(pam_unix)[15340]: session opened for user johnt by (uid=0)
Apr 9 16:32:27 hostfoo login[15340]: Authentication service cannot retrieve user credentials
and I can't log in. So even though pam.d/rlogin likes me, since the auth section of pam.d/system-auth denies me, the login fails.
The bottom line is, no matter what rules you put in the auth section of your pam.d/rlogin (or other service file), if you use pam_stack then the previous rules get ignored. And if you use pam_stack for your account, password, and session sections, then the "service" they check is NOT the service you would expect, e.g., "rlogin", in my case, but the name of the service on the pam_stack.so command line, e.g., "service=system-auth".
Conversely, even if the auth lines in your pam.d/rlogin authenticate you, if the auth lines in your system-auth file don't authenticate you
(my second example), then the account, password, and session lines IN THE system-auth file may not authenticate you either.
This explains why I have gotten pam_listfiles to work great on Solaris, but not on Linux. Solaris doesn't use the pam_stack mechanism, and what you see in your Solaris pam.conf is what you get. This also explains why users can see themselves being authenticated in the /var/log/messages file, yet they are getting denied access to the machine.
My question: Does anyone know why pam_stack discards the previous results of the stack in favor of its own stack? Is this a bug or a feature?
Hope this helps!
best regards,
--johnT
_______________________________________________ Pam-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/pam-list
