Project review: kuserok/an2ln pluggable interface

[Greg Hudson]

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.

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