Issue with pam_dispatch passing incorrect status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Version Pam used:  1.0.1

Operating System:  Linux


I have a system that is configured during auth to run the following modules:



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/


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;




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,







Pam-list mailing list

[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux