From owner-freebsd-current Sun Jan 20 15:31: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 3F6F137B400; Sun, 20 Jan 2002 15:30:57 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0KNUqI27109; Mon, 21 Jan 2002 02:30:52 +0300 (MSK) (envelope-from ache) Date: Mon, 21 Jan 2002 02:30:50 +0300 From: "Andrey A. Chernov" To: Mark Murray Cc: des@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Step5, pam_opie OPIE auth fix for review Message-ID: <20020120233050.GA26913@nagual.pp.ru> References: <20020120220254.GA25886@nagual.pp.ru> <200201202314.g0KNEDt34526@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201202314.g0KNEDt34526@grimreaper.grondar.org> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 20, 2002 at 23:14:13 +0000, Mark Murray wrote: > > The PAM OPIE may only do OPIE authentication. It is entirely up to the > PAM stack to decide what the login policy is. > > (Well, the PAM stack as specified by the pam configs in /etc/pam*) Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. > However - the module may pass on the authentication token (the password) > and any following modules are allowed to use this if they find it. > (look at the try_first_pass and use_fist_pass options). I was thinking about that way but not find a good solution. That way workatround is: 1) In the failure case when Unix (plaintext) passwords are disabled pam_opie can pass specially-generated incorrect password down to pam_unix. 2) pam_unix option must be changed from "try_first_pass" to "use_first_pass", because it asks again for password if "try_first_pass" active, i.e. allows user to enter Unix (plaintext) password again. So we have the same bug, but shifted to one prompt step. I have doubts about 1): what specially-generated incorrect password can be? It seems that any combination is legal and MAY be equal to real password. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message