Re: NSS and PAM

Dag-Erling Smørgrav 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 out.

> 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.
> 
> 
> No, because PAM doesn't control retrieval of the user information.  

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,
-- 
Jacques Vidrine   NTT/Verio SME      FreeBSD UNIX       Heimdal
nectar_at_celabo.org jvidrine_at_verio.net nectar_at_freebsd.org nectar_at_kth.se