Proposed lexer for parsing krb5.conf files

Nicolas Williams Nicolas.Williams at Sun.COM
Tue Nov 22 13:01:41 EST 2005


On Tue, Nov 22, 2005 at 11:22:53AM -0500, Jeffrey Altman wrote:
> Wyllys Ingersoll wrote:
> 
> > I think it is worth some more thought and investigation, there are
> > definite benefits in developing an XML schema for the config data and
> > I don't think it would be all that difficult as compared to rewriting
> > the current profile parsing code.
> > 
> > -Wyllys
> 
> I don't think you grasp the scope of the problem.

Are you saying that no "more thought and investigation" is worth putting
into this?  Why are you discussing details of moving krb5.conf into the
Windows registry then?

>                                                     Kerberos is not
> a library that you replace and suddenly all of the applications that
> use the krb5.conf file become updated.   The Kerberos world is one in
> which there are multiple stacks from multiple vendors on the same
> machine.  Sometimes they are dynamic libraries and sometimes the
> libraries are static.
> 
> On a typical Solaris box you will find Sun's distribution in C plus
> one of the Java variants.  You might also find an MIT and/or Heimdal
> distribution because someone wanted to build/deploy an application
> that requires raw krb5 apis.
> 
> It is not acceptable for an upgrade of one krb5 library to suddenly
> start breaking others.   [...]

Nobody said krb5.conf should go away.  Think of storing krb5 config data
in XML (e.g., in SMF in Solaris, or not in XML but in the Windows
registry, if you like) and then having a krb5.conf writer that
generates, for the benefit of legacy apps/libraries, krb5.conf given the
actual authoritative source for krb5 config data.  Yes, yes, there exist
profile APIs for updating krb5.conf, but these are not widely used, so
something might be done about those without too much complication.

Anyways, I'm not trying to design a solution here, but to point out that
this problem is worth more thought and investigation.

Nico
-- 


More information about the krbdev mailing list