Date: Sun, 16 Feb 2003 02:55:56 +0300 From: "Andrey A. Chernov" <ache@nagual.pp.ru> To: Dag-Erling Smorgrav <des@ofug.org> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpam/modules/pam_opieaccess pam_opieaccess.c Message-ID: <20030215235556.GI72156@nagual.pp.ru> In-Reply-To: <xzpof5dm7jg.fsf@flood.ping.uio.no> References: <200302152326.h1FNQnAr027546@repoman.freebsd.org> <20030215233943.GC72156@nagual.pp.ru> <xzpof5dm7jg.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 16, 2003 at 00:46:27 +0100, Dag-Erling Smorgrav wrote: > "Andrey A. Chernov" <ache@nagual.pp.ru> writes: > > There is no needs to explicately allow localhost in /etc/opieaccess. It is > > already works by default, as designed, see OPIE code. > > It does not work by default; pam_opieaccess previously had special- > case code to handle this (by explicitly allowing non-OPIE logins when > PAM_RHOST was NULL). This behaviour was very surprising to people who > wanted to prevent OPIE users from using their passwords even locally, > as they had no way of knowing that login(1) happened to set PAM_RHOST > to NULL for local logins. It means that pam_opieaccess() tries to handle localhost before accessfile.c instead of correctly passing "" there for localhost case. > > /etc/opieaccess changes breaks POLA. > > How? They preserve historical behaviour while allowing admins to > implement a stricter policy, should they wish to do so. In non-PAMified OPIE environment there was no needs to directly specify localhost in /etc/opieaccess. Old configurations becomes broken after your change because miss "new" addition. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030215235556.GI72156>