From owner-freebsd-current@FreeBSD.ORG Thu Dec 4 07:42:39 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 15A4B16A4CE for ; Thu, 4 Dec 2003 07:42:39 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC1E43F93 for ; Thu, 4 Dec 2003 07:42:36 -0800 (PST) (envelope-from nectar@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id E14815489C; Thu, 4 Dec 2003 09:42:35 -0600 (CST) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 80622-03; Thu, 4 Dec 2003 09:42:24 -0600 (CST) Received: from lum.celabo.org (ofc-fw.sterling.verio.net [161.58.128.247]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 96B34548A3; Thu, 4 Dec 2003 09:42:24 -0600 (CST) Received: from freebsd.org (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id 9D6A0150637; Thu, 4 Dec 2003 09:42:23 -0600 (CST) Message-ID: <3FCF55DF.7040402@freebsd.org> Date: Thu, 04 Dec 2003 09:42:23 -0600 From: Jacques Vidrine User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031202 Thunderbird/0.4RC1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <20031129011334.GC88553@madman.celabo.org> <20031201142737.GC99428@madman.celabo.org> <20031201175925.GC244@madman.celabo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Thu, 04 Dec 2003 15:42:39 -0000 Dag-Erling Sm=F8rgrav said the following on 12/1/03 4:24 PM: > You are bringing authorization into the fray... we're talking about > directory services (retrieving information about a user) and > authentication (identifying someone as that user), not authorization. Yes, you are right--- I *am* bringing authorization into the fray, because I assumed that is what you meant. I can see someone confusing authorization and authentication and believing that they should be combined. However, I did not think that someone might do the same with directory service functions such as: * looking up a person's phone number * getting a list of printers * resolving a host name or a protocol name So, let's agree on at least one thing: directory services and authentication are two different, separate things. Then we can continue arguing about whether authorization and authentication are two different, separate things. They are. :-) Ultimately, though, NSS is a directory services API (or rather, the functions which are supported by NSS, such as getpwnam, gethostbyname, and so on are the API). Authorization services are very often built upon directory services, but they are not the same thing, as you point ou= t. > The problem is that the authentication information needs to be stored > somewhere, and the usual solution is to store it in the directory, so > changing the password involves both authentication and directory > services. Storing passwords in the directory is a historical mistake, and `shadow password files', Kerberos, and additional authentication methods are, in part, attempts to correct this mistake. [...] >>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. >=20 >=20 > No, because PAM doesn't control retrieval of the user information. =20 You don't need `user information' in order to change a password. All you need is your username, and your current password--- or maybe just the former if you have administrator privileges. > If > it did, it would be as simple as you say, but it doesn't - NSS does - > so it's a nightmare. Imagine the case where different directories > contain different entries for the same user, or for different users > who happen to have the same name; this is standard practice with NIS. There is no such thing as different users with the same name. If the users have the same name, then they are the same user. Of course you must take into account namespaces as well... the `des' account on freefall.freebsd.org is not necessarily the same user as the `des' account on any other UNIX box in the universe :-) > Which directory do you write the modified entry into? The obvious > answer is "the one it came out of in the first place", but PAM doesn't > know which one that was. Applications that use PAM to change the password when the password expires seem to work out OK. Maybe this is a complication of the trickiness of stacking in PAM? At any rate, the possible existence of deficiencies in PAM does not somehow make it any less of a problem that passwd(1) mixes up directory services and authentication. (I almost wrote 'mixes up authorization and authentication' above, but you are right: in this case passwd(1)'s folly is even more obvious.) The semantics here can quickly get confusing when we are not being very precise. But, I didn't really want to go down the road where it would matter. :-) I just wanted to point out that there are strong reasons why the functionalities that NSS and PAM provide are implemented as separate APIs: they are truly separate concepts. Cheers, --=20 Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se