From owner-freebsd-hackers Wed Aug 4 15: 6: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 53DA914A2E for ; Wed, 4 Aug 1999 15:05:53 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40327>; Thu, 5 Aug 1999 07:46:11 +1000 Date: Thu, 5 Aug 1999 08:05:35 +1000 From: Peter Jeremy Subject: Re: NSS Project In-reply-to: <5loggno44q.fsf@assaris.sics.se> To: assar@sics.se Cc: hackers@FreeBSD.ORG Message-Id: <99Aug5.074611est.40327@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. I definitely wouldn't like to get into 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 (or has been corrupted somehow). 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). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message