Implementing preauthentication using loadable modules
nalin at redhat.com
Mon Oct 2 09:27:34 EDT 2006
On Fri, Sep 29, 2006 at 03:59:14PM -0400, Jim Rees wrote:
> My client plugin interface essentially just adds entries to the pa_types
> table. The ftable contains a list of pa_types_t entries, each of which has
> a INFO/REAL flag, a preauth type, and a preauth procedure pointer.
> The only advantage to mine is that different preauths can have different
> flags. I don't know how useful that is.
It's probably a toss-up. We could either have the flags be
per-mechanism, or require that mechanisms which provide different flags
be implemented as separate modules. For PKINIT, the latter seems
sufficient. A third option is to let libkrb5 get the client flags by
calling a callback, the way the server does. In that case, the preauth
type would have to be passed in....
Any objections to changing so that the client flags are provided by a
callback, and to make the client and server callbacks take the preauth
type as an argument?
> You probably also should have a version number field.
The name of the symbol which the module exports is implicitly being used
for this. It doesn't provide for major/minor versioning, though (the
module is either compatible with the library's expectations, or it
More information about the krbdev