On Wed, Jun 23, 2010 at 4:13 AM, Alan DeKok <aland@deployingradius.com> wrote:

> I do not think pam_radius_auth is behaving wrongly - looking at the
> code is simple enough, I do get "All RADIUS servers failed to respond"
> in the SYSLOG, so it should clearly be returning PAM_IGNORE as documented.

Double-check that it's returning PAM_IGNORE. Maybe source code mods
to syslog "RETURNING PAM_IGNORE".

If it is returning PAM_IGNORE, then it's a PAM problem. Ask the
question again on the PAM list.

I've added logging at the end of talk_radius() to confirm that it was returning PAM_IGNORE, and it was indeed the case. I posted to the pam list, where someone suggested I used pam_debug to see how the stack reacted to PAM_IGNORE:

------8<-------
auth required pam_debug.so auth=ignore

auth required /lib/security/$ISA/pam_env.so

auth        sufficient    /lib/security/$ISA/pam_unix.so debug audit likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so
auth       required     pam_nologin.so
------8<-------

I can indeed login with the local auth via pam_unix in this case, so I'm back at looking at the module's code.. I know talk_radius() is returning PAM_IGNORE, here's the very last part of the function with my mod:

------8<-------
if (!server) {
    _pam_log(LOG_ERR, "All RADIUS servers failed to respond.");
    if (conf->localifdown) {
      _pam_log(LOG_ERR, "Retval = PAM_IGNORE");
      retval = PAM_IGNORE;
    } else
      retval = PAM_AUTHINFO_UNAVAIL;
} else {
    retval = PAM_SUCCESS;
}

return retval;
}
------8<-------

I'll have a look at the rest of the flow, see if it could have been overriden elsewhere after that call.. I've never coded a pam module, am I correct to guess that since I'm calling the module with an auth call from the stack I should be looking at pam_sm_authenticate() ?

Martin