From owner-cvs-all Wed Jan 29 15:22:56 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4817D37B401; Wed, 29 Jan 2003 15:22:54 -0800 (PST) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6704C43FC1; Wed, 29 Jan 2003 15:22:47 -0800 (PST) (envelope-from nectar@celabo.org) Received: from opus.celabo.org (opus.celabo.org [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id E6C5E24; Wed, 29 Jan 2003 17:22:46 -0600 (CST) Received: by opus.celabo.org (Postfix, from userid 1001) id AE971591B; Wed, 29 Jan 2003 17:21:05 -0600 (CST) Date: Wed, 29 Jan 2003 17:21:05 -0600 From: "Jacques A. Vidrine" To: Peter Wemm 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> Mail-Followup-To: "Jacques A. Vidrine" , Peter Wemm , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org References: <200301292120.h0TLKcbW064283@repoman.freebsd.org> <20030129224857.271022A89E@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030129224857.271022A89E@canning.wemm.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.1i-ja.1 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 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