(Final?) krb5.Conf Lexer/Parser Proposal

[Jeffrey Altman]

Joseph Calzaretta wrote:
> At 05:51 PM 1/7/2006, Theodore Ts'o wrote:
>> Hence, if the a GUI program tries to use the profile library to
>> display the the results from multiple configuration files, and then
>> tries to edit them, *it*
>> *will* *fail*.  It can't possibly succeed, because the API is simply
>> not adequate to the task.  See?

It will fail depending on what you expect to happen.

>> and it would only allow the calling application to open one file at a
>> time, thus removing the inherent ambiguities and traps in the current
>> implementation.
> 
> That is one way to handle it, although it would (as you mention
> elsewhere) force the calling application to figure out the implications
> of combining several files, meaning that a full-featured profile editing
> tool would need to duplicate much of the work of the profile library
> (merging the trees, for example).  Another way is to expand the API so
> that callers specify a file on which to perform each action.  This is
> not necessarily the right way to do it (gives callers too much power and
> responsibility) but is at least sufficient to get it done.

The discussion as it has progressed makes the assumption that a "profile
editor" is one that displays the entire profile to the end user.  This
is certainly not how the profile data is modified in the existing tools
such as the KFW 2.6 Leash32.exe.  In these tools, a subset of the
profile data is displayed to the user perhaps in a combo box or an
edit field.

When there are multiple configuration files chained there is no
expectation that the user is allowed to edit any of the files other than
the first one.

Think of the behavior that both Danilo and I described earlier in the
thread when the Windows registry is being used.   The combination of
user hive, local machine hive, and executable resource is equivalent
to three profile files.  When the user wants to make a change to a
value the only place where changes are ever made is to the user hive.
It doesn't matter whether the modification is an addition, a change
or a deletion.  All changes are written to the one location the user
is expected to have write permission to.

When there are multiple profiles in use I believe that normal end
users expect that they only location they are going to be able to
make changes to is a configuration file located in their home directory
and that this file is going to be the first file listed in the profile
chain.

As such I expect the profile library to treat the first profile as
read/write and the subsequent ones as read-only.   When changes are
made that require a deletion of data from the read-only profiles
I would expect that the read-write profile would store appropriate
data to be written to the file such that from the end user perspective
the data has been removed even though the profiles from which the
data was obtained have not been altered.

This behavior should be entirely encapsulated within the profile
library and should not require that the application know anything
about how many profiles are in use, where they reside, or how the
data is distributed among the profiles and merged.

Jeffrey Altman