From owner-freebsd-security Mon Jan 22 12:57: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from jenkins.web.us.uu.net (jenkins.web.us.uu.net [208.240.88.32]) by hub.freebsd.org (Postfix) with ESMTP id 84EE437B402 for ; Mon, 22 Jan 2001 12:56:40 -0800 (PST) Received: by jenkins.web.us.uu.net (Postfix, from userid 515) id CDEE112686; Mon, 22 Jan 2001 15:56:24 -0500 (EST) To: djm@web.us.uu.net, n@nectar.com Subject: Re: Fwd: [PAM broken design? pam_setcred] Cc: freebsd-security@freebsd.org Message-Id: <20010122205624.CDEE112686@jenkins.web.us.uu.net> Date: Mon, 22 Jan 2001 15:56:24 -0500 (EST) From: djm@web.us.uu.net (David J. MacKenzie) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > That's all fine and good, but pam_sm_setcred in pam_krb5 is unlikely > to get called. > > This is roughly what is happening (example has config with pam_skey > then pam_krb5): > > application: pam_authenticate() > libpam: pam_dispatch() > pam_skey: pam_sm_authenticate() /* fail */ > pam_krb5: pam_sm_authenticate() /* success */ > application: pam_setcred() > libpam: pam_dispatch() > pam_skey: pam_sm_setcred() /* success */ > pam_krb5: /* not called */ > > Does that make it clearer? Ya... So, a combination of the pam_get_item technique that pam_krb5 uses, and the Solaris (not Linux-PAM) behavior for dispatching pam_sm_setcred(), would do what you want, right? Given that multiple pam_sm_authenticate() functions might have succeeded, we could either do like Solaris and overkill, calling all auth modules' pam_sm_setcred() functions, or we could keep some state--a list of the auth modules whose pam_sm_authenticate() functions succeeded. That's what you suggested originally, I believe. That approach assumes that applications that don't call pam_authenticate(), such as ones that use Kerberos for authentication, also shouldn't call pam_setcred(). Perhaps that's reasonable; again, it's poorly documented. Which way it is matters to me for my MIT krb5 PAM patches. It would probably be simpler to be compatible with the undocumented Solaris dispatch behavior. Here is a patch to do that that is at least close to being right. I'm not 100% sure that it handles all combinations of return values in various orders the same way that Solaris does. --- contrib/libpam/libpam/pam_handlers.c 2001/01/22 20:19:52 1.1 +++ contrib/libpam/libpam/pam_handlers.c 2001/01/22 20:22:44 @@ -500,6 +500,8 @@ #endif char *mod_full_path=NULL; servicefn func, func2; + int actions2buf[_PAM_RETURN_VALUES]; + int *actions2 = actions; int success; D(("called.")); @@ -649,6 +651,19 @@ _sym = "_pam_sm_authenticate"; _sym2 = "_pam_sm_setcred"; #endif + actions2 = actions2buf; + /* Always run the pam_sm_setcred for all listed auth modules. + Otherwise, we can end up not running the pam_sm_setcred + for auth module(s) that authenticated successfully, + e.g. if an earlier auth module is "sufficient" and + its authenticate fails but its setcred succeeds. + This is also apparently what Solaris PAM does. */ + { + int i; + for (i = 0; i < _PAM_RETURN_VALUES; i++) + actions2[i] = _PAM_ACTION_IGNORE; + actions2[PAM_SUCCESS] = _PAM_ACTION_OK; + } break; case PAM_T_SESS: handler_p = &the_handlers->open_session; @@ -780,7 +795,7 @@ (*handler_p2)->must_fail = must_fail; /* failure forced? */ (*handler_p2)->func = func2; - memcpy((*handler_p2)->actions,actions,sizeof((*handler_p2)->actions)); + memcpy((*handler_p2)->actions,actions2,sizeof((*handler_p2)->actions)); (*handler_p2)->argc = argc; if (argv) { if (((*handler_p2)->argv = malloc(argvlen)) == NULL) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message