(Final?) krb5.Conf Lexer/Parser Proposal

[Joseph Calzaretta]

At 09:32 AM 1/9/2006, Theodore Ts'o wrote:
>I wouldn't you expand the API so the callers specify a file on which 
>to perform each action; that makes the API much more unweildy (how
>*do* you specify which file you want to perform the action; it's OK 
>to specify non-existing files to profile_init_path, so it can't be 
>numerically).  In any case, this is exactly the same as restricting 
>the read/write API to only opening one file at a time, and then 
>forcing the applicaition to open each file separately --- in either 
>case, the application is still shouldering the responsibility of 
>figuring out the impliciation of combining several files.

Not if the API also tells the application which relations come from 
which files (sorry if I left that out).  So if an application wants 
to delete some relation, it would first ask the library where that 
relation lives, and then tell the library to delete the relation out 
of that file.  Or it could tell the library to delete the relation 
out of some other file, which would either fail (if no finalizer 
syntax or if you specify a file later in the chain) or succeed (by 
using the finalizer to get it done, if possible.)  The application 
could use, by default, the user file to add relations.  But if the 
application was some special super admin tool, it could specify any 
file in the chain it wanted.  In all of these cases, the application 
does not have to precalculate/recalculate the implications of its 
actions; it would receive this information from the library.

(Oh, as for specifying files, if you passed a non-existent tile to 
profile_init_path(), then I imagine such a file should be created 
when flushing back to that file.  That's what I'd want to happen 
anyway...  so files could be specified numerically, unless I'm 
missing something.)

Please understand, I'm not suggesting that particular method 
seriously, as it does make the API quite unwieldy and gives too much 
power and responsibility to the calling application.  I would expect 
some kind of reasonable default behavior which largely shields the 
calling application from having to know what's stored where.  If 
there's no finalizer syntax, then the library deletes things from 
where they are, and (by default) adds things to the first file in the 
chain.  If there is finalizer syntax (with sufficient power to 
delete  relations), then it makes all changes on the first file in 
the chain unless the application says otherwise.  Again, some of 
these changes could fail (Sorry, you can't delete that relation here, 
that relation is read-only here.) if the application specifies 
something nonsensical.

I don't want to get too sidetracked on exactly what the new API will 
look like right now (although I understand that it's not fully 
decoupled from the syntax discussion).  My original point was just 
that whatever the new API turns out to be, it will be powerful enough 
to do programmatic editing of the profile.

>It would probably make things easier in this case to consider adding 
>the concept of a finalizer not just to a section, but to an individual
>relation, and to also extend the profile to support the concept of a 
>"whitespace" relation, marks a relation as deleted.

So, for example,
foo = {
     bar = *
}
would prevent future files in the chain from creating a foo/bar = baz 
relation?  Cool.

Without such extensions (or something like them) it seems to be not 
just harder but generally impossible to make minimal changes in the 
user file (i.e., changes that don't affect seemingly unrelated 
sections of the profile).   If the API has to override and duplicate 
an entire section just to change one relation, the next time the 
system file updates that section, the user's profile will be 
inexplicably (to the user) stuck with some stale version.  In which 
case, it could be argued that the best thing for the API to do is to 
always override the entire system file; at least the whole thing will 
be stale instead of just some part.  Eh, maybe not. :-P Anyway I 
agree that if we do decide to support finalizer syntax of some form, 
it would have to be powerful enough to make minimal changes.

--Joe

Joe Calzaretta
Software Development & Integration Team
MIT Information Services & Technology