From owner-freebsd-current@FreeBSD.ORG Mon Dec 1 09:59:51 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 C1F5E16A4CF for ; Mon, 1 Dec 2003 09:59:51 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5F7A43FA3 for ; Mon, 1 Dec 2003 09:59:26 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 34E525489C; Mon, 1 Dec 2003 11:59:26 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id BEB816D455; Mon, 1 Dec 2003 11:59:25 -0600 (CST) Date: Mon, 1 Dec 2003 11:59:25 -0600 From: "Jacques A. Vidrine" To: Dag-Erling Smørgrav Message-ID: <20031201175925.GC244@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Dag-Erling Smørgrav , freebsd-current@freebsd.org References: <20031129011334.GC88553@madman.celabo.org> <20031201142737.GC99428@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 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 17:59:51 -0000 On Mon, Dec 01, 2003 at 05:48:22PM +0100, Dag-Erling Smørgrav wrote: > They are different issues, but in this context you can't discuss one > without the other. Authentication doesn't work unless you have a user > to authenticate. It makes no sense to separate them; you just end up > duplicating a lot of concepts and code. Hmm, I disagree completely. :-) They can be separated and should be separated. Systems that mix them up are flawed. The confusion of the two are what *causes* the problem you bring up below (passwd(1)). Authentication simply names you. It is quite possible to be authenticated in some context and have absolutely no privileges or other information (``in a vacuum'', if you will). It is even useful in some cases: = `Junk' certificates = `Junk' Kerberos principals = A disabled account = A newly-created account More practically speaking, the mechanism by which you authenticate usually has no bearing on what you are authorized to do. This is the power of properly separating authentication and authorization: regardless of whether I authenticate by entering my password, inserting my smart card and PIN, or supplying a Kerberos ticket, my privileges will be the same [1]. Similarly, if the IT department moved from NIS to LDAP over the weekend, all my existing authentication tokens naturally still work. That's not to say that you *cannot* combine authentication and authorization, but they are naturally independent and different protocols and semantics are required for one and the other. RADIUS is a good example. It is quite difficult to properly support a variety of authentication mechanisms in RADIUS. Diameter addresses the issue by supporting a separate authentication protocol, EAP, which in turn allows for various authentication mechanisms generically. > Also, is changing your password an authentication function or a > directory function? I don't think you can answer either without > answering both. I think it is strictly an authentication function. The change in your password has no affect on your UID, or your phone number, or in what ACLs your name appears in. > > I guess I think of it this way. If NSS had not been implemented > > `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then > > applications that used the UNIX directory service APIs would need to > > be re-written in order to utilize NSS. That's a lot of code to change > > for little benefit. > > Backward compatibility is fine, but NSS does not seem to export an API > that we can use when we want to lift ourselves out of the mud, so we > are forced to keep rooting around in it. What's an example of what you mean? The BSD nsswitch implementation has a generic nsdispatch(3) that allows for new applications, but I'm not sure that is what you mean. At any rate, it is not `NSS' proper, it is an implementation detail. > One consequence of this (and > of the artificial separation between NSS and PAM) is that passwd(1) > doesn't work properly except in the simplest cases. It seems to me that this is a direct result of passwd(1) confusing authentication and authorization. Other than determining the default target user name from the current UID, passwd(1) needs only to invoke PAM interfaces to change your password for any authentication method that supports password changing. Of course this won't work for certain legacy, read-mostly `authentication methods' such as NIS or Hesiod that aren't supported by PAM. > > If I understand you correctly, you believe that it would be possible > > to unite the NSS and PAM switches, so that they used the same > > configuration file, dynamic loading mechanisms, cascading, and so > > on. Sure, I think that's possible. There might even be some benefit, > > though probably not enough benefit to abandon PAM/NSS and go our own > > way. > > Not to go our own way, no. There's the rub. It would have to be a > reasonably wide effort; we'd need to get at least one major Linux > distro to adopt the same infrastructure. Indeed, ``there's the rub'' :-) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se [1] Mostly. An application might require that you used a strong authentication method, to launch the nukes or something. :-)