NSS and PAM

[Jacques A. Vidrine]

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 at celabo.org jvidrine at verio.net nectar at freebsd.org nectar at kth.se


[1] Mostly.  An application might require that you used a strong
authentication method, to launch the nukes or something. :-)