Date: Mon, 22 Jan 2001 08:54:59 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: "David J. MacKenzie" <djm@web.us.uu.net> Cc: freebsd-security@freebsd.org Subject: Re: Fwd: [PAM broken design? pam_setcred] Message-ID: <20010122085459.A93103@hamlet.nectar.com> In-Reply-To: <20010119210820.111B912686@jenkins.web.us.uu.net>; from djm@web.us.uu.net on Fri, Jan 19, 2001 at 04:08:20PM -0500 References: <20010119210820.111B912686@jenkins.web.us.uu.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 19, 2001 at 04:08:20PM -0500, David J. MacKenzie wrote: > > Regardless of whether you authenticate with `skey', `krb5', or `unix', > > pam_sm_setcred is called in pam_skey.so, i.e. the module search starts > > over. By my reading of the Solaris man page, pam_sm_setcred should be > > called in the module that successfully authenticated the user. At any > > rate this seems infinitely more useful. > > > > Excerpt from Solaris 2.6 pam(3): > > > > If the user has been successfully authenticated, the application > > calls pam_setcred() to set any user credentials associated with > > the authentication service. [...] For example, during the call to > > pam_authenticate(), service modules may store data in the handle > > that is intended for use by pam_setcred(). > > I think the PAM spec is unclear on this. > The way ports/security/pam_krb5 handles this situation is: > > In pam_sm_authenticate() it does: > > if ((pamret = pam_set_data(pamh, "ccache", ccache, cleanup_cache)) != 0) { > DLOG("pam_set_data()", pam_strerror(pamh, pamret)); > (void) krb5_cc_destroy(pam_context, ccache); > pamret = PAM_SERVICE_ERR; > goto cleanup; > } > > In pam_sm_setcred() and pam_sm_acct_mgmt() it does: > > if (pam_get_data(pamh, "ccache", (const void **) &ccache)) { > /* User did not use krb5 to login */ > DLOG("ccache", "not found"); > return PAM_SUCCESS; > } > > That is, if there's no data stored by its authenticate function, > that means the user authenticated using some other PAM module. > So it punts and returns success (meaning "I pass, no-op" in this case). > This seems reasonable. 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? -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org 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?20010122085459.A93103>