The Kerberos client now supports configuration snippets
The `/etc/krb5.conf` file now loads configuration snippets from the `/etc/krb5.conf.d/` directory. This enables compliance with existing distribution configuration standards and crypto policies management. As a result, users can now split configuration files and store the snippets in the `/etc/krb5.conf.d/` directory.
+++ This bug was initially created as a clone of Bug #1146370 +++
Description of problem:
It would be beneficial for packages like realmd or SSSD if krb5 supported dropping configuration snippets to two new directories owned directly by libkrb5:
The former would be used by the machine administrator and the latter by the distribution. One proposed use-case would be the loading of SSSD localauth plugin, which could then by done simply by SSSD dropping a config file to /usr/share/krb5.conf.d/
This is required for a seamless SSSD localauth plugin enablement.
FreeIPA side: https://fedorahosted.org/freeipa/ticket/4514
SSSD localauth plugin: https://bugzilla.redhat.com/show_bug.cgi?id=1145788
What to test:
- when a krb5.conf snippet is dropped in /usr/share/krb5.conf.d/, it should be processed
- when a krb5.conf snippet is dropped in /etc/krb5.conf.d/, it should be processed
- When there is a snippet targeting the same option in both /usr/share/krb5.conf.d/ and /etc/krb5.conf.d/, the /etc/krb5.conf.d/ one should "win"
Roland, please feel free to extend this.
SSSD RHEL Bugzilla with the local auth plugin: Bug 1135043
(In reply to Martin Kosek from comment #3)
> What to test:
> - when a krb5.conf snippet is dropped in /usr/share/krb5.conf.d/, it should
> be processed
> - when a krb5.conf snippet is dropped in /etc/krb5.conf.d/, it should be
> - When there is a snippet targeting the same option in both
> /usr/share/krb5.conf.d/ and /etc/krb5.conf.d/, the /etc/krb5.conf.d/ one
> should "win"
^^^ What's about the legacy /etc/krb5.conf? Should it have higher precedence than these new locations?
- I'd like also suggest one more test that should verify the "ini-file" nature of krb5.conf. Having the same configuration section (configured within  ) in two (or three different files), but each is setting a different parameter. In the result booth parameters should be correctly set. This is to verify that only configuration parameters take precedence and not whole sections.
> Roland, please feel free to extend this.
(In reply to Patrik Kis from comment #6)
> > - When there is a snippet targeting the same option in both
> > /usr/share/krb5.conf.d/ and /etc/krb5.conf.d/, the /etc/krb5.conf.d/ one
> > should "win"
> ^^^ What's about the legacy /etc/krb5.conf? Should it have higher precedence
> than these new locations?
We are still discussing the final design, but from my POV, the logical order of processing should be
/usr/share/krb5.conf.d/ - snippets provided by packages
/etc/krb5.conf.d/ - snippets provided by admin
/etc/krb5.conf - default, main configuration file.
The /etc/krb5.conf definitely needs to stay there, many programs expect it to be there and we cannot break anything.
> - I'd like also suggest one more test that should verify the "ini-file"
> nature of krb5.conf. Having the same configuration section (configured
> within  ) in two (or three different files), but each is setting a
> different parameter. In the result booth parameters should be correctly set.
> This is to verify that only configuration parameters take precedence and not
> whole sections.
Just to summarise here the least disruptive method we have to deal with adding a configuration directory:
The krb5 package should creater and own /etc/krb5.conf.d/ (and maybe /usr/share/krb5.conf.d/).
The default krb5.conf file will be change to source /etc/krb5.conf.d/ using the 'includedir' directive.
Software can drop immutable config snippets in /usr/share/krb5.conf.d/ and then symlink them in /etc/krb5.conf.d/ (we need to check if krb5-libs follow symlinks here).
This allows software to drop immutable files but also allow the admin to disable unwanted snippets.
Software should not install snippets or symlinks in /etc/krb5.conf.d/ with rpm but only as part of some explicit configuration tool (ipa-client-install, realmd, ad-cli, etc...).
Given that krb5.conf is defined as (noreplace):
%verify(not md5 size mtime) %config(noreplace) /etc/krb5.conf
the new drop in directory will not work on upgraded machines until admin merges the changes in .rpmnew file. Is that correct?
(In reply to Martin Kosek from comment #10)
> Given that krb5.conf is defined as (noreplace):
> %verify(not md5 size mtime) %config(noreplace) /etc/krb5.conf
> the new drop in directory will not work on upgraded machines until admin
> merges the changes in .rpmnew file. Is that correct?
Correct and intended.
sigh I meant "intentional"
Created attachment 948872 [details]
Old prototype patch (for reference only)
Attached is the old prototype patch ("krb5_etckrb5confd_prototype001.diff.txt"; for reference purposes only). Wasn't accepted by upstream because |fmemopen()| is new in POSIX.2008 (and therefore not available on older platforms) and because it's an hack (basically injecting a "includedir" directive via a |fmemopen()|-based "virtual file").
(real patch after lunch)
Created attachment 949045 [details]
Prototype patch (tested on Solaris 11, Illumos, Fedora F20, RHEL, FreeBSD 10).
Upstream pull request is https://github.com/krb5/krb5/pull/225
(In reply to Roland Mainz from comment #15)
> Created attachment 949045 [details]
> Prototype patch
NACK this, we MUST NOT source active configuration fropm /usr/share
/usr may be read-only and that would make it impossible for admins to disable unwanted configuration. The only active configurationj should be in /etc/krb5.d where admins can remove or change files.
During the design and development of this RFE we found out that a solution for this RFE is more complicated than initially assessed. Given there is still not a clear agreement on the design between upstream&RHEL, the best way is to not rush it in RHEL-7.1 and postpone it so that it can receive proper design.
SSSD localauth snippet registration will be done via other means:
I am thus removing this bug as a blocker to SSSD bug.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.