Date: Wed, 6 Feb 2002 01:28:31 +0300 From: "Andrey A. Chernov" <ache@nagual.pp.ru> To: Mark Murray <mark@grondar.za> Cc: des@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c Message-ID: <20020205222829.GA9120@nagual.pp.ru> In-Reply-To: <200202052219.g15MJhs32408@greenpeace.grondar.org> References: <20020205214703.GA8579@nagual.pp.ru> <200202052219.g15MJhs32408@greenpeace.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 05, 2002 at 22:19:38 +0000, Mark Murray wrote: > > On Tue, Feb 05, 2002 at 23:59:08 +0300, Andrey A. Chernov wrote: > > > > > It is OK at this point, but broken _after_ PAM called. > > > Lets imagine srandom(33) produce this hypotetical sequence for random() > > > calls: > > > > To see the bug, run following test application with "call_pam" set to 1 > > and 0 > > The bug is doing userland stuff before the authentication IMO. 1) Program must be able prepare yourself before auth, some operations like initializations, server key generations etc. can take a long time and when daemon starts, he do that _before_ starting auth. 2) The fact that random() and srandom() are unsafe in the libraries discussed almost in every Unix book I saw with usual recommendation to avoid them in the general purpose libraries. I don't see any reason why PAM is so special to not follow this rule. 3) All programs behave like they _owns_ random() internal state and not expect any damages from the libraries here. If you want PAM be special, it must be well documented in all visible PAM manpages and docs. -- 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?20020205222829.GA9120>