From owner-freebsd-arch Mon May 28 23: 2:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 1104937B423 for ; Mon, 28 May 2001 23:02:29 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f4T62A654885; Tue, 29 May 2001 08:02:12 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200105290602.f4T62A654885@gratis.grondar.za> To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. References: <20010528174728.A39588@xor.obsecurity.org> In-Reply-To: <20010528174728.A39588@xor.obsecurity.org> ; from Kris Kennaway "Mon, 28 May 2001 17:47:29 MST." Date: Tue, 29 May 2001 08:04:27 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > The only danger area I can see is the need to check root password to > > get to single-user if the console is not secure. This needs to work > > even if (and especially when) the system is hosed. I wouldn't like to > > see init become dependent on the dynamic loader and various PAM > > libraries in this case. > > We also compile all of the PAM modules included in the base system > into a static libpam which allows statically-linked binaries to work, > up to a point (they won't work if the system administrator tries to > use a third-party PAM module) I'll stay out of the static stuff as long as I can for exactly this reason. Init(8) will be especially left alone. :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message