[Comment] [krbdev.mit.edu #9117] profile write operation interactions with multiple files

[Julien Rische via RT]

http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9117
This is a comment.  It is not sent to the Requestor(s):

I just wanted to highlight the fact that for Fedora, CentOS, and RHEL,
we try to keep the content of the first krb5 configuration file
(/etc/krb5.conf) to the minimum (mainly libdefaults global
parameters)[1].

We start the file by including the /etc/krb5.conf.d configuration
folder. This allows us to have a more modular configuration system. It
is very convenient to delegate realm configuration and domain/realm
mapping to application maintainers. We also do so to delegate
permitted encryption types configuration to system-wide policy tools.

With the points above in mind, I have the following concerns about the
current limitations of the profile API for our case:

* About profile_add_relation(), the mention "at the end of the first
file's values for the relation, but before any values appearing in
other files" is confusing me. I was having the impression that
relations were added to the tree in the file parsing order. At least I
believe that if a value A is set for a certain parameter in a
sub-file, before the value B being set to the same parameter in the
first file, the list of resolved values will still be "A, B" (in this
order). So even if the trees of all files are not merged, it seems the
parsing order does still apply somehow.
* profile_clear_relation(), profile_update_relation(), and
profile_rename_section() will only have effect on the few default
settings from /etc/krb5.conf. In our case most of these relations are
single value parameters. If there are multiple values set for this
kind of parameters the first one is selected. This tends to confuse
users a lot, because it seems the norm for configuration files is the
variable assignment logic (the last assignment of a given parameter in
the parsing order is the one that is actually applied), which is the
complete opposite of the present approach. Hence if some
/etc/krb5.conf parameters are overridden in /etc/krb5.conf.d/*, these
3 functions won't have any effect on these parameters, since the
relations they will modify in /etc/krb5.conf are not the ones that are
resolved first.

If I got it right, the FreeRDP use case is to export a modified
version of the tree where the list of KDC addresses for a given realm
is replaced by another address. I believe the reason why they use such
an approach is because of the "*" marker limitation for relations in
subsections[2]. If this was supported, they could simply configure
KRB5_CONFIG with a generated file such as:

    [realms]
    EXAMPLE.COM = {
      kdc* = kdc.example.com
    }
    include /etc/krb5.conf

This would completely override any /realms/EXAMPLE.COM/kdc relations,
while still applying the rest of the system configuration.

[1] https://src.fedoraproject.org/rpms/krb5/blob/rawhide/f/krb5.conf
[2] https://github.com/krb5/krb5/blob/krb5-1.21.2-final/src/util/profile/final2.ini#L1-L3