Proposed lexer for parsing krb5.conf files

Theodore Ts'o tytso at MIT.EDU
Tue Nov 22 14:41:33 EST 2005


On Tue, Nov 22, 2005 at 01:30:21PM -0500, Wyllys Ingersoll wrote:
> I disagree here, Jeff.  I do grasp the problem and understand all
> too well the need to maintain backwards compatibility.  I was not
> suggesting that support for the current profile be broken or
> abandoned.  I propose that if you are going to the trouble of rewriting
> the profile code, why not take some time to design it such
> that it can evolve in a more standard format that can
> be specified by a schema (XML) and processed by third party apps
> and libraries?  XML can be as easily parsed in Windows
> as it can in Unix, registry entries cannot.

Speaking as the person who originally came up with the profile format,
the design goals were:

*) Easy to read and understand how to use (because getting help
	writing documentation has always been hard)

*) Easy to extend when we need new configuration parameters (yes, XML
	can do that too).

The main reason why I chose not to use XML originally were:

1) Back then there weren't all that many XML editors out there, and
many of the tools that wrote XML ended up writing them out in a way
that made them completely impossible for a human to parse.

2) Many XML libraries are complete and utter bloatware:

% ls -l /usr/lib/libxml2.so.2.6.22
1080 -rw-r--r--  1 root root 1100496 Nov  2 13:39 /usr/lib/libxml2.so.2.6.22

compare and contrast that to the profile library implementation which
I already did; it's smaller by some two orders of magnitude...

Many people already understood the windows-style profile configuration
file; it is intuitively obvious what it means, and can be easily
edited using a text editor.  XML is much more difficult....

> Nothing says you cannot maintain backwards compatibility with
> the old format.  As I said, some simple pre-processing of the
> config file would easily reveal the format and tell the
> code how to proceed - use XML or use the old format.

Bad idea, not with the same filename, at least.  What happens to old
krb5 libraries or old applications statically linked with old krb5
libraries that don't understand XML?

If you want to choose the a different name, say /etc/krb5.xml, and
then you don't mind linking with some large, bloated XML library, be
my guest.  Of course, some people who have to live with
applications/libraries using both config files would probably
appreciate code that can synchronize the two config files --- at which
point one really has to ask the question about whether there are
enough benefits with XML that in this specific case, it is worthwhile
to use the politically correct data format.  Or whether this is more
about religion than anything else.


Me, I prefer this as the perfect balance between conciseness and
making things easy to parse:

[realms]
        ATHENA.MIT.EDU = {
                kdc = kerberos.mit.edu:88
                kdc = kerberos-1.mit.edu:88
                kdc = kerberos-2.mit.edu:88
                kdc = kerberos-3.mit.edu:88
                admin_server = kerberos.mit.edu
                default_domain = mit.edu
        }
        MEDIA-LAB.MIT.EDU = {
                kdc = kerberos.media.mit.edu
                admin_server = kerberos.media.mit.edu
        }
        ZONE.MIT.EDU = {
                kdc = casio.mit.edu
                kdc = seiko.mit.edu
                admin_server = casio.mit.edu
        }

compared to this:

<realm name="ATHENA.MIT.EDU"><kdc port="88">kerberos.mit.edu</kdc>
<kdc port="88">kerberos-1.mit.edu</kdc><kdc port="88">kerberos-2.mit.edu</dc> 
<kdc port="88">kerberos-3.mit.edu</dc><admin_server>kerberos.mit.edu</admin_server>
<default_domain>mit.edu</default_domain></realm> <realm name="MEDIA-LAB.MIT.EDU">
<kdc>kerberos.media.mit.edu</kdc><admin_server>kerberos.media.mit.edu</admin_server></realm>
<realm name="ZONE.MIT.EDU"><kdc>casio.mit.edu</kdc><kdc><seiko.mit.edu</kdc>
<admin_server>casio.mit.edu</admin_server></realm>

(which far too many XML programs/libraries used to emit)

or even this:

<realm name="ATHENA.MIT.EDU">
	<kdc port="88">kerberos.mit.edu</kdc>
	<kdc port="88">kerberos-1.mit.edu</kdc>
	<kdc port="88">kerberos-2.mit.edu</dc> 
	<kdc port="88">kerberos-3.mit.edu</dc>
	<admin_server>kerberos.mit.edu</admin_server>
	<default_domain>mit.edu</default_domain>
</realm> 
<realm name="MEDIA-LAB.MIT.EDU">
	<kdc>kerberos.media.mit.edu</kdc>
	<admin_server>kerberos.media.mit.edu</admin_server>
</realm>
<realm name="ZONE.MIT.EDU">
	<kdc>casio.mit.edu</kdc>
	<kdc><seiko.mit.edu</kdc>
	<admin_server>casio.mit.edu</admin_server>
</realm>

But "De gustibus non est disputandum", I suppose....  


						- Ted


More information about the krbdev mailing list