On Tue, 24 Sep 2002, Dan Melomedman wrote:

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

No, the point is that after you've authenticated the user, with AFS, you
then perform system calls to load info into the kernel to continue
verifying who you are to the AFS servers.

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

See above. Some auth methods have steps that have to happen after you get
the OK/FAIL knowledge, to fully make use of the system. For AFS, you load
tokens. For Kerberos, you set an environment variable to point to the
ticket file.

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

You want to redesign them just so they fit into one particular
authentication model? They work fine now, and have worked for over ten
years. That sounds like putting the cart before the horse.

Take care,

Bill