From owner-cvs-all  Tue May  8 17:19:49 2001
Delivered-To: cvs-all@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id E013D37B422; Tue,  8 May 2001 17:19:41 -0700 (PDT)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id f490Jce11091;
	Tue, 8 May 2001 17:19:38 -0700 (PDT)
Date: Tue, 8 May 2001 17:19:38 -0700
From: Alfred Perlstein <bright@wintelcom.net>
To: Brian Feldman <green@FreeBSD.org>
Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/crypto/openssh auth-pam.c
Message-ID: <20010508171938.Q18676@fw.wintelcom.net>
References: <200105082230.f48MUJH20777@freefall.freebsd.org> <20010508171418.P18676@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010508171418.P18676@fw.wintelcom.net>; from bright@wintelcom.net on Tue, May 08, 2001 at 05:14:19PM -0700
X-all-your-base: are belong to us.
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Alfred Perlstein <bright@wintelcom.net> [010508 17:14] wrote:
> * Brian Feldman <green@FreeBSD.org> [010508 15:30] wrote:
> > green       2001/05/08 15:30:18 PDT
> > 
> >   Modified files:
> >     crypto/openssh       auth-pam.c 
> >   Log:
> >   Since PAM is broken, let pam_setcred() failure be non-fatal.
> 
> Basically the new PAM code has the idea of cached credentials.  Besideds
> being a really fun fun thing to get right, the API does some funky
> things.
> 
> Basically, setcreds expects to be able to use cached credentials
> from some previous call.  My guess is that it expects to use them
> from pam_authenticate().  I'm not sure if sshd calls pam_authenticate()
> when doing RSA/DSA keys which is why the cached credentials are bogus.
> 
> I'm going to work on a quick fix and possibly email around to help
> figure out if my fix is correct.

Actually "cached" is probably wrong even though that's what they call
the value, the real meaning seems to be "frozen" such that one can
rely on the value of the credential not changing while performing
operations on it.

The problem is this snipped of code in pam_dispatch:

        if (use_cached_chain) {
            /* a former stack execution has frozen the chain */
            cached_retval = *(h->cached_retval_p);
        } else {
            /* this stack execution is defining the frozen chain */
            cached_retval = h->cached_retval = retval;
        }

        /* verify that the return value is a valid one */
        if ((cached_retval < PAM_SUCCESS)
            || (cached_retval >= _PAM_RETURN_VALUES)) {
            retval = PAM_MUST_FAIL_CODE;
            action = _PAM_ACTION_BAD;
        } else {

when pam_setcred() is called use_cached_chain is set, however the
cached value has not been iniatialized.

Do you know what the proper way to initialize it would be?  It looks
like pam_authenticate() would be the right one, however I have a 
feeling it wants to pop up a password dialog which would be a bit
odd over the net.


-- 
-Alfred Perlstein - [alfred@freebsd.org]
http://www.egr.unlv.edu/~slumos/on-netbsd.html

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