On Tue, 24 Sep 2002, Dan Melomedman wrote:

> Here are some of my thoughts about PAM as an authentication system:
>
> Too complex than needs to be. Why loadable libraries as part
> of the design? Why not a client/server model? Or even a simpler exec
> chain model such as checkpassword or CVM? In a client/server design, the
> modules (executables) could all conform to the same simple interface for
> passing credentials to the server. This would allow the modules to be
> either statically or dynamically linked; a sysadmin would have a
> choice. Debugging would be trivial, the modules themselves would be much
> smaller in size, and the API could be very simple.

I can't say why loadable modules are part of the design of PAM, but I do
know why a number of NetBSD developers want a loadable-module system.
Because the other systems (well, not sure about CVM) you mention above are
too limiting. The problem with a fork/exec model is that, as I understand
it, all it can do is say yes or no. There are a number of authentication
schemes that neem more than that. Like AFS, where you need in-kernel
"tokens." These are kerberos credentials that AFS uses. They must be
loaded IN THE PROCESS. No form of helper authentication method can
substitute for that.

The problem with the client/server approach is similar; you can only
perform methods expressable in the client/server protocol. To try and do
something else, you have to change the client code. Which means, without
dynamic modules, relinking everything. The whole point is to try and be
able to add new authentication methods w/o relinking, so that really
doesn't cut it.

> Why loadable modules again? Because the designers tried to avoid
> fork/exec overhead? Or a message over socket overhead? Is the overhead
> really that high to warrant such a design? Measure it, you'll note some
> other syscalls take far more CPU than fork/exec.

See above. At least for us, it's not a question of optimizing something,
but of fundamental design. If you're doing authentication and you aren't
in the process you're authenticating, you limit what you can do.

> Also I find PAM configuration files confusing, and the whole system very
> hard to debug. I doubt the files are easily parseable, and editable by
> software too. Simplicity and ease of use definitely weren't design goals
> there, IMO.

Is that an issue with design or implementation? NetBSD hasn't come up with
a loadable-security-module implementation yet, so saying we shouldn't do
one because others have done it poorly is premature. Saying what you think
others have done wrong is good, though, and can help us not make said
mistakes.

> Authenticatiion is the easy part, because all you need is request
> username/password, give to the authentication server, and get OK/FAIL.

Nope. While OK/FAIL will go a long way, there are a number of auth systems
it won't do. And that's the whole point above. For those systems, AFS in
particular, you also have to load credentials (make syscalls()) IN THE
AUTHENTICATED PROCESS.

> The problem spot is the NSS library. How to make all the getpw* be
> sysadmin-configurable without too much fuss? I for example am looking
> into ways to make getpw* functions pull everything out of an LDAP
> directory, and can't see how to do this without much fuss in any of the
> BSDs. Linux has nss-ldap which seems to work OK with its NSS library,
> but what if I have a BSD machine on the network? nss-ldap is only
> supported through some BIND library on *BSDs, and it's something I
> wouldn't trust. Writing this support for the current NSS would also mean
> linking the whole LDAP enchilada into it statically, no?

Luke would be the best person to speak to this one. Being able to do this
kind of thing is one of the goals. :-)

Take care,

Bill