From owner-freebsd-hackers Wed Aug 4 20:45:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id F304414BF6 for ; Wed, 4 Aug 1999 20:45:23 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id UAA22310; Wed, 4 Aug 1999 20:44:39 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id UAA02817; Wed, 4 Aug 1999 20:44:38 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Wed, 4 Aug 1999 20:44:38 -0700 (PDT) Message-Id: <199908050344.UAA02817@vashon.polstra.com> To: jeremyp@gsmx07.alcatel.com.au Subject: Re: NSS Project In-Reply-To: <99Aug5.074611est.40327@border.alcanet.com.au> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <99Aug5.074611est.40327@border.alcanet.com.au>, Peter Jeremy wrote: > Assar Westerlund wrote: > >Peter Jeremy writes: > >> We need to be able to build an application that has no dynamically > >> loaded code for recovery purposes (/stand and /sbin) as well as for > >> security. > > > >Isn't that the same problem as with PAM? > > Quite probably PAM has the same problem. I haven't bumped into it > with PAM, so I can't be sure. When you're not sure, it's really best to find out or keep quiet on the mailing list. As it is, you've just created a dozen or so new people all over the world who will go around saying, "Hmm, I seem to remember reading that PAM doesn't work in statically-linked executables" -- which is false. It works fine. It is implemented using a linker set approach which you are encouraged to investigate in the sources. > the situation where init can fail to load (or be unable to validate > the single-user password for a secure console) because the appropriate > encryption library is on a partition that isn't mounted yet If that happened, it would have to be considered a severe design error. > (or has been corrupted somehow). Many things can get corrupted to make the system unrecoverable. For example: the kernel, init itself, entries in the /dev directory, and various combinations of cp, fsck, newfs, restore, ... > The idea of being able to dynamically add new password encrytion > schemes (PAM) or database access methods (NSS) is generally good. > The problems appear when you try to marry these schemes with the > system security and initialisation/recovery tools (which need to > rely on and trust a minimal subset of the system). Well, dynamic linking is here to stay, and that enlarges the scope of "minimal subset" somewhat. But nothing would be qualitatively different if we went to an all-dynamic scheme (which I hope we will do some day). In any case, your system has to be working to a certain degree to be recovered, or else you have to use external media such as the fixit disk. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message