Project review: kuserok/an2ln pluggable interface

[Sumit Bose]

On Wed, Feb 06, 2013 at 12:19:37PM -0500, Greg Hudson wrote:
> On 02/06/2013 04:25 AM, Sumit Bose wrote:
> > About an2ln_all. I think there are two contradicting sentences, "If
> > multiple modules implement an2ln_all, the order in which they are
> > consulted is not defined" and "Module registration will fail ... if it
> > implements an2ln_all and a previous module already implements that
> > method."
> 
> My original plan was that only one module could implement an2ln_all.  I
> relaxed that constraint after deciding it wasn't really necessary, but I
> didn't hit all of the relevant text.  I'll fix it.
> 
> My expectation is that there will be two kinds of modules implementing
> an2ln methods:
> 
> 1. A module which implements something like the old DB: support in
> auth_to_local, for a particular kind of database, or something like the
> current RULE: support but with a different kind of rule processing.  An
> admin might register a few different modules of this type, and might
> invoke the same module multiple times with different parameters.
> 
> 2. A module which just wants to control all an2ln operations (e.g. by
> processing them with sssd).  Most likely only one of these would be
> registered.
> 
> I will put some of this rationale in the project page for clarity.
> 
> > If both an2ln_all and an2ln are available and configured, which method
> > is used first? I guess an2ln comes first.
> 
> Since module an2ln_all methods are invoked before built-in mechanisms
> including auth_to_local rule processing, an2ln_all would come first.
> 
> > Can a module implement both an2ln_all and an2ln?
> 
> I don't see any reason to prohibit this.  The an2ln method would only be
> used if an2ln_all returns KRB5_PLUGIN_NO_HANDLE.
> 
> > I guess module registration will fail if an2ln is implemented without
> > an2ln_types and if an2ln_types is implemented without an2ln?
> 
> The code could check for this, but the simpler thing to do is just never
> invoke the an2ln method in this case.
> 
> > Where will the modules be searched? $(MODULE_DIR)/an2ln ?
> 
> We no longer search for module shared objects in new pluggable
> interfaces.  Instead, they are registered with "module" directives in
> the [plugins] section of krb5.conf.  See
> http://mailman.mit.edu/pipermail/krbdev/2010-July/009171.html and
> responses for rationale.

Thank you for the answers. Just to make sure I understand it correctly.
To make a new an2ln module available I need to add something like:

[plugins]
  an2ln_inteface = {
    module = my_module:/path/to/my_module.so
    enable_only = my_module
  }

to /etc/krb5.conf or to a file an an include directory.

> 
> > Do I understand it correctly that if a modules implements an2ln_all it
> > will extend the default behaviour in the sense that no explicit
> > auth_to_local lines in /etc/krb5.conf are needed?
> 
> That's the idea.  I figured it would be cumbersome for an integrated
> system like IPA to have to register the sssd localauth module *and*
> configure a [realm] -> <defaultrealm> -> auth_to_local line to invoke it.
> 

yes, it would :-). I guess even in the case without explicit
configuration default_an_to_ln() is always called as the last step if
all other modules return KRB5_PLUGIN_NO_HANDLE or an other error code.

bye,
Sumit