From owner-freebsd-security  Fri Jan 19 13: 8:46 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 EE45737B401
	for <freebsd-security@freebsd.org>; Fri, 19 Jan 2001 13:08:20 -0800 (PST)
Received: by jenkins.web.us.uu.net (Postfix, from userid 515)
	id 111B912686; Fri, 19 Jan 2001 16:08:20 -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: <20010119210820.111B912686@jenkins.web.us.uu.net>
Date: Fri, 19 Jan 2001 16:08:20 -0500 (EST)
From: djm@web.us.uu.net (David J. MacKenzie)
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> 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.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message