On 1033002090 seconds since the Beginning of the UNIX epoch
Dan Melomedman wrote:
>

>Does the system really need to do so many things? All I want is one
>module for one type of authentication, with two deterministic resutls -
>success or failure. Simple, easy, and uh, sufficient. Keep it simple,
>stupid.

Really?  On my home systems I use many different kinds of authentication
for myself and my users.  I use kerb5, unix passwds, a tiny bit of
s/key, and RSA Auth (in sshd.)

Right now, /usr/bin/login supports 4 different mechansims: krb5,
krb4, unix passwd and s/key.  But other bits of the system and many
packages in pkgsrc do not support all of them properly.

Having just hacked up both xlock and xdm to work with Heimdal and
looking at doing the same thing to gdm and kdm, I can say that
having some kind of framework for authentication would be rather
useful.

Please also in this discussion consider separately the different
parts of PAM.  It is an entire framework specification that includes
(1) an interface to applications, an (2) interface to modules and
a (3) configuration framework.  We should consider the parts and
the whole and be clear about which part we are discussing at each
point.  It would be unfortunate, if we, e.g. had many programs that
could not interoperate with our authentication system because we
decided against dynamically loadable modules when that is only a
requirement of (3) and it would be possible to implement (1) and
(2) without it.

I think that the interface to applications is a required feature
for NetBSD, even if we do not implement the rest of the framework.
Many third party packages understand PAM, few understand anything
else except for whatever they've implemented which is generally a
subset of what we'd like to support.  (e.g.  [gkx]dm, xlock, etc.)

I also think that it is rather stange that people have come to
accept and even like the fact that authentication configuration is
randomly strewn around the system and not centralised in an easy
to manage way.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/