Skip Menu |

Subject: built in plugins need a method to disable/enable by default
Download (untitled) / with headers
text/plain 1.2KiB
From a recent email thread:

On Wed, May 25, 2016 at 10:58:52AM -0400, Greg Hudson wrote:
Show quoted text
> On 05/24/2016 07:57 PM, Will Fiveash wrote:
> > I have a couple things to bring up about this. One is that it would be
> > nice if there was a way to have a built-in plugin like k5identity
> > disabled by default in the code but still allow an admin to override
> > that in krb5.conf. Currently (in 1.13) I don't see the support for
> > that.
> Our usual approach is that the built-in module can read configuration
> from krb5.conf to configure its behavior or turn itself off. This is
> generally less arcane than requiring configuration in [plugins] would be.

That doesn't work for us because we have many customers with existing
krb5.conf files configured. Trying to modify those config files to
disable k5identity by default on upgrade is non-trivial. What I would
like to see is a way to allow a built-in plugin to be registered but
having a hard-coded default so it is not enabled unless the admin
explicitly enables it in krb5.conf. Doing this via the configure script
would be best so we don't have to patch the MIT code.

At this point we have to completely disable support of k5identity
whether a customer is using NFS sec=krb5 protected home dirs or not
which is not ideal.
We can have a configuration option to enable .k5identity which defaults to
true in the upstream MIT krb5 and defaults to false in Solaris (via a
configure option). I would still prefer to handle this inside
ccselect_k5identity.c rather than in the plugin infrastructure, since
configuration within the plugin infrastructure would be much more arcane
from the administrator's perspective.