Dynamic plugin modules and OS packages

[Nicolas Williams]

On Tue, Jul 13, 2010 at 04:38:52PM -0400, ghudson at MIT.EDU wrote:
>   * Move the plugin search path under /etc, and expect it to contain
>     symlinks to dynamic objects located elsewhere (package-specific
>     subdirs of /usr/lib, whatever).  There may be some resistance to
>     symlinking to binary objects from /etc.

That might be OK, but it's not as good as the next choice:

>   * We add "include" support to the profile library, and the OS adds
>     "include /etc/krb5.conf.d/*" to its standard krb5.conf.  Each
>     plugin package supplies a profile fragment giving the location of
>     the dynamic object and an enable/disable boolean (which may
>     default to on or off depending on the packaging model and/or the
>     plugin).

This means I could edit krb5.conf to include specific plugins's configs
instead of krb5.conf.d/*, if I wanted to.  I like that.

Please do make it so the directory entries read have to have a specific
name form such that one could rename them to get them excluded.  Also,
maybe having a two-digit number prefix for every name + collating the
directory entries in the C locale would help provide for order wherever
it might be needed.

>   * A variation on the above: each plugin supplies its own config

I could certainly see plugins that have additional, separate
configuration that doesn't reside in krb5.conf nor krb5.conf snippets.
I'd not necessarily encourage that, but you can't prevent it from third
parties.

>     fragment which separate from the profile; lets say these fragments
>     canonically live in an /etc/krb5-plugins directory whose location
>     can be overridden by an environment variable.  Each fragment
>     identifies the location of the dynamic object and whether the
>     plugin is enabled (perhaps just by commenting out the pathname).

Please don't add yet another environment variable, not for this.

>   * Continue to use the current discovery mechanism for finding
>     dynamic objects.  Add profile variables to enable and disable
>     plugins by name; imagine something like this:
> 
>       [plugins]
>          preauth = {
>            # Use enable_only to allow only specific preauth plugins.
>            enable_only = pkinit
>            # Alternatively, use disable to disallow preauth plugins.
>            disable = enc_timestamp
>            disable = enc_challenge
>          }

The problem with this is that one ends up having to script the editing
of krb5.conf.  This is NOT packaging-friendly.  Whereas having a
krb5.conf.d/ directory is: pkgs can drop editable configuration file
snippets in there.

>     (We will likely have such filtering options regardless of how
>     discovery works, since we need a way of disabling built-in plugin
>     modules.)  [...]

That's fine.

Nico
--