From owner-cvs-all Sat Jan 19 3:56:20 2002 Delivered-To: cvs-all@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id BDAA637B400; Sat, 19 Jan 2002 03:56:13 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0JBtxE08435; Sat, 19 Jan 2002 14:56:00 +0300 (MSK) (envelope-from ache) Date: Sat, 19 Jan 2002 14:55:57 +0300 From: "Andrey A. Chernov" To: Mark Murray Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpam/modules/pam_opie pam_opie.c Message-ID: <20020119115555.GA8265@nagual.pp.ru> References: <20020119101114.GA7243@nagual.pp.ru> <200201191051.g0JApTt20369@grimreaper.grondar.org> <20020119105943.GB7683@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020119105943.GB7683@nagual.pp.ru> User-Agent: Mutt/1.3.24i 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 Sat, Jan 19, 2002 at 13:59:43 +0300, Andrey A. Chernov wrote: > On Sat, Jan 19, 2002 at 10:51:29 +0000, Mark Murray wrote: > > > > DES has a DARPA contract to work on PAM, and I am the "PAM guy". Please > > at least put this sort of thing up for review. (Looking at the OPIE code > > logs, it could also be said that I am the "OPIE guy"). > > There is no MAINTAINER line in the libpam or /etc/pam.d, so I legally > treat it as "go and fix by yourself". Moreover, I complain about wrong > pam_opie interaction several times starting long time ago and nothing > seems changed or even discussed here. > > Well, since the changes already in, I am ready to discuss every bit of > them. More about pam_opie+pam_unix chain, i.e. how it was broken and is fixed: In old variant pam_opie return two states, PAM_SUCCESS and PAM_AUTH_ERR. 1) If we chain it as "sufficient" and get failure, it falls to pam_unix unconditionally, but must do that only when opiefileaccess()+opiealways() permits. This is dangerous from security sense. 2) If we chain it as "required" and get success, we'll get failure in the next pam_unix in the chain due to wrong password. 3) If we chain it as "requsite" and get failure, it stop whole chain unconditionally, but must fallback to pam_unix when opiefileaccess()+opiealways() permits. 4) If we chain it as "optional", ther is no sense to keep it since non-optional pam_unix is already in the chain. All it means that there must be 3-state machine for pam_opie: PAM_SUCCESS, PAM_AUTH_ERR and some 3rd, PAM_CRED_ERR. In that case we can do 1) for PAM_SUCCESS and PAM_AUTH_ERR and disable fallback to pam_unix for PAM_CRED_ERR case. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message