Date: Sat, 19 Jan 2002 16:37:31 +0300 From: "Andrey A. Chernov" <ache@nagual.pp.ru> To: Jim Bloom <bloom@acm.org> Cc: Kris Kennaway <kris@obsecurity.org>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libpam/modules/pam_opie pam_opie.c Message-ID: <20020119133731.GA9275@nagual.pp.ru> In-Reply-To: <3C4973ED.D048EB70@acm.org> References: <200201191009.g0JA95b91076@freefall.freebsd.org> <20020119042808.A67985@xor.obsecurity.org> <20020119123903.GA8776@nagual.pp.ru> <3C4973ED.D048EB70@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 19, 2002 at 08:26:06 -0500, Jim Bloom wrote: > That was not the case with S/Key under PAM. When I created pam_opie.c, it > behaved identically to pam_skey.c. It is not possible in strict sense, because SKEY and OPIE functions may have subtle differences and simple changing skey* prefix to opie* prefix not means that they behaved identically. Subtle differences mainly comes through various configuration options for OPIE and changing some functions. F.e. tty-level S/key access mechanism is completely removed in OPIE. It definitely NOT improves security (but maybe not lowers it too). > Maybe PAM worked differently from some of > the programs that had S/Key support hard coded in them and the migration to PAM > changed the behavior. Yes, and I try to fix this attempting to stay completely inside PAM concept. See my previous message why pam_opie needs 3-state return code, and can't work properly with 2-state. -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020119133731.GA9275>