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

[Greg Hudson via RT]

Mon Apr 01 12:58:36 2024: Request 9117 was acted upon.
 Transaction: Ticket created by ghudson at mit.edu
       Queue: krb5
     Subject: profile write operation interactions with multiple files
       Owner: Nobody
  Requestors: ghudson at mit.edu
      Status: open
 Ticket <URL: http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9117 >


The profile library supports profile objects containing multiple files.  This
feature is most commonly used in the KDC and similar programs, which merge
kdc.conf and krb5.conf into a single relation tree.  The file structure is
preserved in the memory representation of a profile--that is, instead of
parsing all of the files to generate an in-memory tree, each file is parsed
separately, and query operations iterate over the trees to compose a list of
relation values.

The profile library supports write operations such as profile_clear_relation()
and profile_add_relation().  Modifications can be explicitly written to the
backing file with profile_flush(), implicitly written during profile_release()
(profile_abandon() can be used to omit this), or written to a different file
with profile_flush_to_file().  Comments are lost and includes are flattened
when changes are written.  The Solaris kclient(8) program is the main
historical user of the profile write APIs that I am aware of; it uses these
APIs to programmatically modify krb5.conf.  FreeRDP has introduced another
use: to ephemerally modify the default profile for the purpose of changing the
realm KDC setting for an operation.

Currently, if a profile is modified, modifications happen to the tree
representing the first file in the profile.  Only that tree is marked as dirty
and only that tree's modifications will be written out by a flush operation 
This is fine for kclient, but it does not work well for the FreeRDP use case
if the default profile doesn't contain exactly one file.  If there are no
files, it crashes (ticket 9110, fix pending).  If there are multiple files,
the following edge cases are likely true (though untested):

* profile_clear_relation() will not clear all values of a relation if some of
the values don't come from the first file.
* profile_add_relation() will insert values at the end of the first file's
values for the relation, but before any values appearing in other files. 
* profile_update_relation() will fail if the old value does not appear in the
first file.
* profile_rename_section() will fail if the section does not appear in the
first file, and will leave behind any identically named sections in the second
or later file.