From owner-freebsd-current@FreeBSD.ORG Mon Dec 1 15:24:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD32E16A4CE for ; Mon, 1 Dec 2003 15:24:25 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24EB943FBD for ; Mon, 1 Dec 2003 15:24:14 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 189F1530C; Tue, 2 Dec 2003 00:24:13 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 2A19F5308; Tue, 2 Dec 2003 00:24:06 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id CD82633C7B; Tue, 2 Dec 2003 00:24:05 +0100 (CET) To: Garrett Wollman References: <20031129011334.GC88553@madman.celabo.org> <20031201142737.GC99428@madman.celabo.org> <20031201175925.GC244@madman.celabo.org> <200312012250.hB1MoCMZ081007@khavrinen.lcs.mit.edu> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Tue, 02 Dec 2003 00:24:05 +0100 In-Reply-To: <200312012250.hB1MoCMZ081007@khavrinen.lcs.mit.edu> (Garrett Wollman's message of "Mon, 1 Dec 2003 17:50:12 -0500 (EST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.60 cc: freebsd-current@freebsd.org Subject: Re: NSS and PAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2003 23:24:26 -0000 Garrett Wollman writes: > < > The problem is that the authentication information needs to be stored > > somewhere, and the usual solution is to store it in the directory,=20 > ...which is usually the worst possible place. Please don't penalize > those of us with sensible authentication systems. You're the one trying to penalize other people. A common framework for directory and authentication services can of course store authentication tokens separately from user information, but the reverse isn't true. You can't unilaterally decide to leave out functionality that 90% of our users require just because you are in a position to use (what you consider to be) a better solution. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no