Date: Wed, 29 Jan 2003 17:21:05 -0600 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: Peter Wemm <peter@wemm.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpam/modules/pam_krb5 pam_krb5.c Message-ID: <20030129232105.GA11502@opus.celabo.org> In-Reply-To: <20030129224857.271022A89E@canning.wemm.org> References: <200301292120.h0TLKcbW064283@repoman.freebsd.org> <20030129224857.271022A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 29, 2003 at 02:48:57PM -0800, Peter Wemm wrote: > Jacques Vidrine wrote: > > nectar 2003/01/29 13:20:38 PST > > > > Modified files: > > lib/libpam/modules/pam_krb5 pam_krb5.c > > Log: > > Do not return inappropriate error codes in pam_sm_setcred. > > Doesn't this just hide the problem? I was reacting to a report by Kris of a spurious error message. This was a genuine bug, though harmless besides the message. (There was also a similar, potentially harmful bug that I fixed in this commit.) I guess when you say `the problem' you mean the case where using sshd + pam_krb5 results in a successful login, but without a credentials cache? I thought DES had fixed the problem pam_setcred getting called with the `wrong' handle? > I know there has been lots of > finger pointing about PrivSep and the data being stored in the wrong > process, but even with PrivSep turned *off*, it is still broken. No, privilege seperation doesn't have anything to do with the problem. > I added some tracing code that showed that the cleanup_cache() callback > hook was being explicitly called *before* the sm_setcred function. > ie: there is either a programming error or a design error somewhere > and the setcred stuff cannot possibly ever work (regardless of whether > sshd is hacked to use pthreads or not.. it doesn't even work in a single > process context, therefore it shouldn't have anything to do with the split > contexts). My memory on the issue was stale ... I had to go look at an old thread. To prime other people's cache :-), I'll reproduce some of it here: >On Thu, Nov 14, 2002 at 11:48:51AM -0600, Jacques A. Vidrine wrote: >> For whatever reason (I'm afraid we'll need DES here, or lots >> more looking on my part), sshd sets up two PAM handles for >> authentication: one in auth-pam.c (call it handle 1) and one in >> auth2-pam-freebsd.c (call it handle 2). It then authenticates >> you (calls pam_authenticate) using handle 1, but later does the >> pam_setcred with handle 2 (after handle 1 has been destroyed, for >> that matter). So the credentials are never available to pam_krb5's >> pam_sm_setcred. >On Wed, Nov 27, 2002 at 10:56:49PM +0100, Dag-Erling Smorgrav wrote: >> Our OpenSSH runs PAM authentication in a child process in order to >> fully support challenge-response authentication. This means the >> problem is entirely in *my* code, which means I should be able to >> figure out a way to fix it. I seem to recall that DES then decided to use a single process but seperate threads to do this. Now I don't recall whether this was committed :-) > Again, this doesn't seem to happen on the PAM in RELENG_4, so I have to > wonder if there is a handle management bug (or incompatability) in openpam > or something along those lines. Maybe sshd is doing something funny > that is upsetting openpam, I dont know. I've just stuck a giant #if 0 > around the code. :-( Huh, on RELENG_4, I experience the same problem as on -CURRENT (login successful, but no credentials cache). IMHO, the problem is in the FreeBSD OpenSSH customizations for challenge-response (I think this area has been a sore spot for some time now). I run stock OpenSSH-portable, and it works there. Cheers, -- Jacques A. Vidrine <nectar@celabo.org> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030129232105.GA11502>