Ticket History #9117: profile write operation interactions with multiple files

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.
 

Some thoughts about the potential solutions here:

* The null solution is to document that profile write operations can only affect the first file.  This essentially leaves the FreeRDP use case broken for some (probably rare) configurations, as there would be no way to guarantee that the realm KDC values from the default profile are cleared and replaced.

* We could make profile_clear_relation() work using the final flag, and leave the other modification operations broken for multiple files.  This is closer to a comprehensive fix than it first seems, as pretty much any FreeRDP-like use case is likely to start with profile_clear_relation() to clear out any values of affected relations from the default profile.  The final flag currently only applies to sections, but we could make it apply to relations as well.  The relation and its containing sections may not appear in the first file, so profile_clear_relation() would have to develop additional logic to add a dummy relation and mark it deleted/final if there are values in subsequent files.  Although this solution requires a lot of special-case logic within profile_clear_relation(), it requires far fewer changes than any of the following ones.

* We could augment the tree data model to support the kind of overrides necessary to make all of the write operations work within the first file while semantically affecting the values across all files.  For instance, profile_rename_section() might need to place tags in the source and destination nodes of the first file's tree, indicating that subsequent files' trees should contain no values at the source and the source section's values at the destination.  The number of edge cases for this solution is pretty large, and the profile data model is already stretched pretty fine, but this option provides the cleanest semantics without changing any caller-visible aspects of the profile model.

* We could create an operation to flatten a multi-file profile into a single tree, rendering all of the write operations effective on data originating from any of the files.  This operation could be explicit, or could be implicit on rw_setup() or profile_copy().  Making it explicit requires attention from callers, who might not realize it is necessary to handle rare configurations.  Making it implicit on rw_setup() calls into question the implicit flush that happens in profile_release(), as the flattened profile would potentially have different contents than the original backing file.  Flattened profiles would also need to be marked NO_RELOAD, which might be problematic if flattening is implicit on profile_copy().

Even if the "*" finalization marker was supported for subsection relations,
I believe that only works across files specified in the search path.
E.g., a KRB5_CONFIG file that specified "/etc/krb5-1.conf:/etc/krb5-2.conf",
it would work finalize a section in krb5-1.conf. But files included
using the "include" directive don't count as separate files for
this purpose. Sadly this makes finalization much less useful.

--Ken