Issue with pam_dispatch passing incorrect status

Jared Smith (jarsmith) jarsmith at cisco.com
Fri Oct 9 16:32:56 UTC 2009


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

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pam-list/attachments/20091009/74681fd2/attachment.htm>


More information about the Pam-list mailing list