Dynamic plugin modules and OS packages

[ghudson@MIT.EDU]

Our current mechanism for discovering dynamic plugins is, I think,
oriented towards the Debian model of operating system packages.  In
the Debian model, a package is responsible for enabling and
configuring itself at install time, so it is important for there to be
a simple mechanism for enabling addon functionality.  For Kerberos
plugins, that mechanism is to install the plugin shared object in a
directory like /usr/lib/krb5/plugins/preauth, where it will
automatically be discovered.

In some other packaging models such as RPM, a package is only
responsible for installing the executable material associated with the
package, and enabling and configuring it is the responsibility of
other mechanisms (kickstart, cfengine, manual editing of config files,
whatever).  Our discovery mechanism is not particularly friendly to
this model of packages:

  * If the package installs the dynamic object in
    /usr/lib/krb5/plugins/preauth, it will automatically be enabled.

  * If the package installs the dynamic object elsewhere and the admin
    enables it through a symlink, then the admin is modifying stuff
    under /usr/lib, which is in principle read-only.

An example of a practical issue which arises is (if I understand
right) there being two conflicting implementations of the KDC location
plugin.  In the Debian model, you'd solve that with package conflict
declarations; in the RPM model, that would be contrary to policy.

Since we're mucking around with the plugin infrastructure, it might be
good if we had a discovery mechanism which was friendly to both
packaging models.  Here are some possibilities:

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

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

  * A variation on the above: each plugin supplies its own config
    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).

  * 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
         }

    (We will likely have such filtering options regardless of how
    discovery works, since we need a way of disabling built-in plugin
    modules.)  Operating systems using RPM-like packaging models might
    add explicit enable lists in their standard krb5.conf, and use
    those to manage which plugins are enabled by default.  My sense is
    that this doesn't satisfy the needs of non-Debian operating
    systems very well, but I'm throwing it out there.

For people who have an interest in OS packaging, which of these is
most attractive, or are there other more attractive options?