Date: Mon, 22 Jan 2001 15:56:24 -0500 (EST) From: djm@web.us.uu.net (David J. MacKenzie) To: djm@web.us.uu.net, n@nectar.com Cc: freebsd-security@freebsd.org Subject: Re: Fwd: [PAM broken design? pam_setcred] Message-ID: <20010122205624.CDEE112686@jenkins.web.us.uu.net>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010122205624.CDEE112686>