From owner-freebsd-current Sun Jan 20 15:44:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 133EF37B400; Sun, 20 Jan 2002 15:44:21 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0KNiFn91597; Sun, 20 Jan 2002 23:44:15 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id g0KNijt34738; Sun, 20 Jan 2002 23:44:45 GMT (envelope-from mark@grondar.za) Message-Id: <200201202344.g0KNijt34738@grimreaper.grondar.org> To: "Andrey A. Chernov" Cc: des@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Step5, pam_opie OPIE auth fix for review References: <20020120233050.GA26913@nagual.pp.ru> In-Reply-To: <20020120233050.GA26913@nagual.pp.ru> ; from "Andrey A. Chernov" "Mon, 21 Jan 2002 02:30:50 +0300." Date: Sun, 20 Jan 2002 23:44:44 +0000 From: Mark Murray 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. Sure - but you are making specialised use of the return value that assumes that pam_opie will be followed by pam_unix. This violates the PAM spec. > > 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. You may be able to do something with options. Example: if the sysadmin allows a password to be passed down the stack, otherwise pass a dummy. (like ftpd auth required pam_opie.so keep_password or similar) > 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. Nope. kill the password if it is not allowed. Pass a NULL. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message