Version Pam used: 1.0.1 Operating System: Linux I have a system that is configured during auth to run the
following modules: pam_securetty.so pam_env.so pam_tally.so pam_radius_auth.so pam_unix.so pam_deny.so I have a situation where I want securetty to have the
behavior that it says uid != 0 == OK and also consider NULL as ok(Yeah this is
a bit odd but I’m doing some custom stuff in later modules that take care
of that). So I’ve setup the entry in the login config file as: auth [success=ok
new_authtok_reqd=ok user_unknown=ok ignore=ignore
default=bad]/lib/security/pam_securetty.so My assumption was that “user_unknown==ok” would
get the user_unknown to look the same as a record exists and not cause
problems. But I’ve found that the status gets set to 10
PAM_USER_UNKNOWN and since securetty is required it causes the auth to bomb out
after it processes the remaining modules since the bad status seems to continue
to propagate through each module. I believe what is happening is it does get processed in the
following block: case
_PAM_ACTION_OK: case
_PAM_ACTION_DONE:
if ( impression == _PAM_UNDEF ||
(impression == _PAM_POSITIVE && status == PAM_SUCCESS) ) {
/* in case of using cached chain
we could get here with PAM_IGNORE - don't return it */
if ( retval != PAM_IGNORE || cached_retval == retval ) {
impression
= _PAM_POSITIVE;
status = retval;
}
} D(("ACTION
DONE OR OK: -- IMPRESSION= %d", impression));
if ( impression == _PAM_POSITIVE && action == _PAM_ACTION_DONE ) { goto
decision_made;
}
break; What I found is that impression was 0 when it enters this
block so I’m assuming that was because of the user_unknown=ok however
that causes it to set status = retval which sets that status ==10 which seems
like it should not occur as that causes status to stay 10 through all the
following modules. When it enters this block later it does have a
positive impression assuming radius succeeds but status == 10 not PAM_SUCCESS
so it never re-sets the status. Wondering why on the first “if” it has
impression == _PAM_UNDEF and if changing that would cause bad side
effects otherwise. My other fix could just be to tweak the securetty module to
consider NULL user entry OK and not tweak the configuration entry to say
user_unknown ==ok but I wanted to see if there is something simple I’m
overlooking here that can be done in the configuration file to make this work? Thanks for any advice on this matter, Jared |
_______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list