* 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