A fork of the profile library code....

Theodore Ts'o tytso at MIT.EDU
Thu Jan 5 05:03:49 EST 2006

Just for people's information, I recently revisited the profile
library code that I wrote ten (!) years ago, and have simplified it
and boiled it down for my own purposes.  I have also added some new
features as well.  

If you want to take a look at it, you can find it at:


Click on the files profile.c, profile.h, profile_helpers.c,
profile_helpers.h, and prof_err.et for the profile source files.

Some comments about the revised code:

- I've folded everything into a single C file (profile.c) which can
  dropped into an application.  (profile_helpers.c, and
  profile_helpers.h are only needed for building the test driver
  program.)  I have not tried to make a library out of it since (a)
  I'm not convinced the API is in the final form, and (b) I want to
  avoid potential namespace conflicts with the profile library shipped
  with krb5.

- A lot of extraneous features have been removed; as a result, the
  entire profile.o that would be used by a typical application is
  under 6k.

- I've removed all functions relating to modifying the profile
  programmatically.  My original conception was something which would
  allow multiple config files to be queried as a single set (i.e.,
  having an /etc/krb5.conf and an ~/.krb5rc file), with the
  appropriate merging of sections and order-sensitive relations (for
  things like KDC's).  The addition of a programmatic interface to
  modify the files was an after-thought, and was not well-defined.
  Furthermore, the majority of applications using the profile library
  would only need a read-only interface.  Besides, the whole point of
  using a text file instead of some horrible format like XML was so that
  it could be easily modified with a text editor.

- I've added the ability to have comments at the end of any line.
  Unlike the lexer proposal, however, the only change which I made
  to the original format was that relation values may not contain 
  spaces unless they are surrounded by double quotes.  (The reason why
  I didn't implement comments was purely because of the lack of double
  quote support.)  Hence, for my parser:

	tag = value foo

  is not legal, although it previouslly was accepted by the profile
  library; one must specify

	tag = "value foo"	# This is a comment


- Other differences from the lexer proposal; I chose _not_ to support
  for arbitrary double quotes anywhere in the profile; there's no real
  need for tag names or section names with spaces, and I wanted to
  keep things as simple as possible.

- I've added the ability for the profile to be given a directory, in
  order to support /etc/foo/conf.d style configuration directories.
  If a directory is given to profile_init(), then each file in the
  directory which matches the regexp ^[0-9a-zA-Z]*$ will be read in,
  in lexigraphical sort order.  (i.e, like Debian's run-parts).  This
  can be useful for applications where the config file is split into
  separate pieces for the convenience of packaging systems such as dpkg
  and rpm.

- I've added a callback hook so that syntax errors can be reported to
  the user with filename and line numbers.  In keeping with the
  original KISS principle, I wasn't interested in elaborate error
  recovery mechanisms, including ones where the application might try to
  decide for itself whether or not an error could be ignored.  

I doubt that the resulting library will be useful for the MIT Kerberos
distribution; it may be that a much more heavyweight, all singing, all
dancing, fully thread-safe and locking-enabled implementation will be
more suited for krb5.  However, I wanted to take the profile library
back to its roots and my original design intention, and something
which was small, elegant, lightweight, and easy to maintain and use in
other applications.  

Comments welcome.

						- Ted

More information about the krbdev mailing list