Bug 1146945 - RFE: Kerberos should support dropping configuration snippets to /etc/ and /usr
Summary: RFE: Kerberos should support dropping configuration snippets to /etc/ and /usr
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Robbie Harwood
QA Contact: Patrik Kis
Marc Muehlfeld
URL:
Whiteboard:
Keywords: FutureFeature
Depends On: 1146370
Blocks: 1207552
TreeView+ depends on / blocked
 
Reported: 2014-09-26 12:18 UTC by Martin Kosek
Modified: 2016-11-03 20:22 UTC (History)
11 users (show)

(edit)
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.
Clone Of: 1146370
(edit)
Last Closed: 2016-11-03 20:22:15 UTC


Attachments (Terms of Use)
Old prototype patch (for reference only) (2.32 KB, patch)
2014-10-21 10:05 UTC, Roland Mainz
no flags Details | Diff
Prototype patch (4.18 KB, patch)
2014-10-21 16:29 UTC, Roland Mainz
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2591 normal SHIPPED_LIVE Low: krb5 security, bug fix, and enhancement update 2016-11-03 12:10:29 UTC
Red Hat Bugzilla 1135043 None CLOSED [RFE] Implement localauth plugin for MIT krb5 1.12 2019-02-06 11:21 UTC
Red Hat Bugzilla 1145788 None CLOSED Enable the sssd krb5 localauth plugin by default 2019-02-06 11:21 UTC
Red Hat Bugzilla 1207552 None CLOSED authconfig does not configure /var/lib/sss/pubconf/krb5.include.d/ when called by realm join 2019-02-06 11:21 UTC

Internal Trackers: 1135043 1145788 1207552

Description Martin Kosek 2014-09-26 12:18:24 UTC
+++ 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/

Comment 1 Martin Kosek 2014-09-26 12:21:28 UTC
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

Comment 3 Martin Kosek 2014-09-26 15:25:27 UTC
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.

Comment 4 Martin Kosek 2014-09-26 15:50:26 UTC
SSSD RHEL Bugzilla with the local auth plugin: Bug 1135043

Comment 6 Patrik Kis 2014-09-29 07:45:24 UTC
(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.

Comment 8 Martin Kosek 2014-09-29 07:54:44 UTC
(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.

Comment 9 Simo Sorce 2014-09-29 14:27:37 UTC
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...).

Comment 10 Martin Kosek 2014-09-30 07:24:11 UTC
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?

Comment 11 Simo Sorce 2014-09-30 16:15:37 UTC
(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.

Comment 12 Simo Sorce 2014-09-30 16:15:53 UTC
sigh I meant "intentional"

Comment 14 Roland Mainz 2014-10-21 10:05:07 UTC
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)

Comment 15 Roland Mainz 2014-10-21 16:29:16 UTC
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

Comment 16 Simo Sorce 2014-10-21 19:29:59 UTC
(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.

Comment 17 Martin Kosek 2014-10-23 12:39:22 UTC
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.

Comment 33 errata-xmlrpc 2016-11-03 20:22:15 UTC
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


Note You need to log in before you can comment on or make changes to this bug.