(Final?) krb5.Conf Lexer/Parser Proposal

[Alexandra Ellwood]

On Jan 6, 2006, at 3:15 PM, Theodore Ts'o wrote:
>
> When Alexis wrote that the finalizer doesn't matter for single-value
> tags, what she meant by that is if the application uses the
> profile_get_integer, profile_get_string, et. al. convenience
> functions, only the value from the first relation is returned.  So
> even though there are two default_realm relations specified, only the
> first one will be looked at by the krb5 library.
>
> Now, it's a bit misleading to talk about "single-value tag" since
> there is nothing special which sets them off as "single value tags" in
> the config file, and indeed the profile library doesn't even recognize
> "single-value tags" a concept.  Also, it is at least theoretically
> possible for a program to query a relation via an interface which
> returns the first matching tag, as well as the more general interface
> which returns all possible matching relations.

That is correct.  I was using the term "single value tag" to refer to  
relations which have only one value from the standpoint of the  
Kerberos libraries.  The profile library collapses sections and  
subsections but not relations.  In other words the following on-disk  
config file:

[section]
	subsection = {
		relation = A
		relation = B
	}
	subsection = {
		relation = C
		relation = A
		subsection = {
			relation = A
			relation = B
		}
	}
[section]
	subsection = {
		relation = D
		relation = B
		subsection = {
			relation = C
			relation = B
		}
	}

will be translated into the in-memory structure:

[section]
	subsection = {
		relation = A
		relation = B
		relation = C
		relation = A	
		relation = D
		relation = B
		subsection = {
			relation = A
			relation = B
			relation = C
			relation = B
		}
	}


(Note: In the current profile code this would only happen if  
duplicated sections and subsections appear in different config  
files.  If they appear in the same config file the later ones would  
be orphaned in the tree structure and never seen by the parsing  
code.  My understanding is that Joe intends to fix this to achieve  
the above behavior so that the behavior for multiple files is the  
same as if they were concatenated together in search order.)


 From the standpoint of the profile library there's no difference  
between a relation that can only have one value and a relation that  
can have multiple values.  However, in practice when the libraries  
look up the value of "section" -> "subsection" -> "relation" they  
either only look at the first value ("A") or look at the whole list  
("A","B","C","A","D","B").  How the libraries treat a given tag  
matters a great deal when looking at what you can do when the profile  
gets merged.


--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>