Bill Studenmund wrote:
> With a generic client in each binary, you have to trust the running server
> it talks to. It can get exploited and then all clients are opened up.
> While there can (and probably will) be bugs in auth modules, they have to
> get exploited each time you fire up the binary; you can't exploit once and
> have the whole system (unless you can engineer the exploit to happen on
> startup of a module).

You're not limited to using client/server. I think an exec chain is the simplest,
and easiest system to implement. Since there are no long-running processes in
this system, it will also benefit from such OS facilities. See checkpassword and
cvm.

> Also, some auth methods, like Kerberos ones, already are client/server, so
> adding an additional client/server step seems very strange to me.

Why? Would you rather rewrite each utility to support Kerberos just
because Kerberos uses client/server? The problem is people want to
switch from one such system to another. If I use Kerberos today (which I
wouldn't want to touch with a 15 foot pole by the way), doesn't mean I
won't use some other method tomorrow. I'd gladly use LDAP support if it
was built into all the utilities needing authentication, but it isn't.
If /usr/bin/login used a simple protocol to communicate with an
authenticator, it would be very trivial to write your own. It would also be
trivial to debug these components. They would do one job only.

It's also important to see the difference between the external 
sources of information. Kerberos and SASL are frameworks, where
LDAP is a protocol to talk to hierarchical directories (which is all
anyone needs for a standardized, centralized authentication/administration
as a back-end, by the way).

The "login"'s job for instance is to get credentials and shove them to
an authenticator, not do several jobs at the same time - which is a mess.
login on systems which use PAM is linked to their PAM library by
contrast.