Bill Studenmund wrote:
> 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.

I can't see why it can't be done. Maybe because I am not familiar with
kerberos or AFS. e.g., a parent loads credentials into a known file
descriptor - 3, then fork/execs a child process which reads these.
Or this won't work either with AFS for some reason?

> 
> 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.

Clients can be static or dynamic in a client/server model. The server
can do most of the work, and the protocol can be simple, in my view. The
advantage of this is, actually the numerous clients which conform to the
same protocol; and the numerous authenticating servers which conform to
the same protocol. But I think an exec chain is even more suitable, and
simpler for this.

Example:
/usr/bin/login is configured by an administrator to fork/exec one of the
available authenticators like an ldap module, which will then change
it's process state through environment, do suid/gid, and exec the job,
like a shell. In the AFS case, why wouldn't a process needing AFS
data be able to read them as passed down by a module? Because AFS i
authentication is misdesigned perhaps? I am guessing here.

> > 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.

Design, and implementation as it is currently with Linux, FreeBSD, etc.
They're quite similar. Take a look at one of the PAM modules available
for these systems, they seem too big for what they accomplish, at least
because of their API. Take a look at their configuration files. In my
opinion - confusing. Debugging PAM issues is far from straight-forward
too.

> > 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.

Could it be those systems need a redesign for simplicity's sake?