Proposed lexer for parsing krb5.conf files

Alexandra Ellwood lxs at MIT.EDU
Tue Nov 22 14:57:38 EST 2005


Most of this had already been said, but I think a summary might help
clarify things:

Many sites use multiple implementations of Kerberos simultaneously on
the same machine.  If only one of those two implementations understands
the new format, the old implementation will get stale data whenever the
new one is used to write to the new file because it can't read the new
format.  Thus, in order to provide forwards and backwards  
compatibility we
need to write not only a legacy krb5.conf reader but also a writer and
simultaneously write both formats by default.

The reason we're re-writing the existing profile library is that it has
thread safety issues and is written in a manner that makes it very
difficult to modify without introducing buffer overruns and new thread
safety issues.  In addition, the API for modifying the profile is
difficult to use to implement a GUI for editing the profile.  Basically,
this means we can't reuse the existing code.

Given that we have to rewrite the "legacy" parser *and* writer, also
writing an XML parser/writer is extra work, and isn't necessary to make
forward progress.  If we decide we want to switch to XML, I would argue
that any XML parser/writer should be a separate project scheduled after
this one so that our projects stay small and manageable.  This is
especially true since Joe is on loan from another team at MIT.

That being said, when Joe presents his new API, if you find places where
the API unnecessarily exposes the implementation such that it would be
hard to change the file format in the future, please do point them out.
I imagine we don't want to tie the on-disk configuration format to the
profile API if we can help it.


Hope this helps,

--lxs

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




More information about the krbdev mailing list