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>