Red Hat Bugzilla – Bug 1146945
RFE: Kerberos should support dropping configuration snippets to /etc/ and /usr
Last modified: 2016-11-03 16:22:15 EDT
+++ 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: /etc/krb5.conf.d/ /usr/share/krb5.conf.d/ 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. Related trackers: 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 > 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" ^^^ 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. Ok.
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 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: https://fedorahosted.org/sssd/ticket/2473 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. https://rhn.redhat.com/errata/RHSA-2016-2591.html