(Final?) krb5.Conf Lexer/Parser Proposal
Alexandra Ellwood
lxs at MIT.EDU
Fri Jan 6 16:10:15 EST 2006
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.ezproxyberklee.flo.org/lxs/www>
More information about the krbdev
mailing list