krb5 DAL (database abstraction layer) and related changes

[Ken Raeburn]

Hi, all.  As I said in mail a while back, I've checked in a bunch of
changes from Novell implementing a database abstraction layer.  The
original code was only made to work on Linux, and made a few
assumptions that won't hold in other environments where our code is
used.  I've done some cleanup, but more is needed.  (Some of the
changes weren't available in the code drop made available for the
Samba team's review, or in the design docs circulated to a few
people.)

** locking changes

Novell introduced read-write locks for use around database calls, so
that multiple LDAP queries can run in parallel without blocking the
KDC.  The new code hardcoded the use of POSIX mutex and condition
variable constructs.  That won't work on Windows.  Also, all the
platforms we run our regular tests on at MIT include support for the
newer POSIX read-write locks with pretty much the same functionality.

I've been thinking for a while that read-write locks could improve
parallelism in a few places in our existing code (e.g., replay cache
scanning).  So I'm leaning towards adding some additional interfaces
to the shim layer, based on the POSIX rwlock interface and the current
mutex shims:

  (typename) k5_rwlock_t
  (initializer) K5_RWLOCK_PARTIAL_INITIALIZER
  int k5_rwlock_init (k5_rwlock_t *);
  int k5_rwlock_finish_init (k5_rwlock_t *);
  int k5_rwlock_destroy (k5_rwlock_t *);
  int k5_rwlock_rdlock (k5_rwlock_t *);
  int k5_rwlock_wrlock (k5_rwlock_t *);
  int k5_rwlock_unlock (k5_rwlock_t *);
  void k5_rwlock_assert_rdlocked (k5_rwlock_t *);
  void k5_rwlock_assert_wrlocked (k5_rwlock_t *);
  void k5_rwlock_assert_unlocked (k5_rwlock_t *);

Since the plugin modules may wish to use locking internally, and we
don't want to force all builds to always link in thread support just
yet, the actual implementations of all of these macros (and the
existing ones) will be pushed off from k5-thread.h into the support
library (with krb5int_* names), and allocation interfaces added:

  int k5_mutex_alloc (k5_mutex_t **);
  int k5_mutex_free (k5_mutex_t *);
  int k5_rwlock_alloc (k5_rwlock_t **);
  int k5_rwlock_free (k5_rwlock_t *);

These will allocate and free initialized, unlocked locks.  Static
storage and compile-time initialization can still be used within the
krb5 libraries, but using the above allocators will avoid the build of
a database plugin needing to know what configuration options were used
for the krb5 code.  (I still expect it'll need access to krb5 internal
header files though.)

** build system changes

Under a normal shared-library build, the module to be loaded is built
as a shared library but installed into a separate directory.  Some
bugs: New rules were added for building the target, but we already had
rules for the same target name, causing some versions of make to error
out, some to choose one rule, and some to choose the other.  Sometimes
versioned names were used, sometimes not.  A ".so" suffix was
hardcoded.

I'm tweaking a copy of the shared-library rules to build the database
module, without the duplicate rules, without the versioned names,
without installing into the main library directory.  It's still got
some ways to go.

Under static builds, it looks like the module is supposed to be linked
in to the executable.  Since we've been shifting towards shared
library builds, I'm going to take the simple approach for now of
always loading the shared object, even if the main Kerberos libraries
themselves are static.  Static builds aren't going to be a top
priority, though.

This is going to make things tricky on the Mac, since we normally
force static builds.  It's going to stay broken for a little while;
once I get the normal UNIX setup working a bit better, I'll address
the Mac problems.

It would probably do unfriendly things to the Windows build too,
except we aren't building the KDB code on Windows currently.

** error handling

Novell made some changes (not checked in) that incompatibly changed
the com_err library interface.  There are enough other packages using
com_err, and other implementations we need to be compatible with, that
the change they made just isn't an option.  When I get a chance to
look at what they're doing a little more closely, I'll try to figure
out if an extension to the com_err interface or something else makes
more sense.

There's also the matter of some proposed extensions (from Doug Engert,
I think?) to how we track errors within the krb5 libraries, so that we
can incorporate more contextual information.  Unfortunately, this may
touch on i18n issues, so isn't something we can knock off in a couple
hours.

I'm not sure, yet, how closely tied these two issues are going to be.

** config files

In the current implementation, all the database module configuration
information is looked up in the main krb5.conf, not in the KDC's own
config file kdc.conf.  I'll see if I can fix this; it may require some
interface changes.

** DAL interface

...  I'm working up from basic build problems, haven't had a lot of
time to look at the DAL interface itself.

One item in the data structure currently is a flag indicating whether
the database module is thread-safe.  I think we want to just require
that it be thread-safe, and make the module do its own locking
internally if it's got parts that aren't thread-safe (like our old
db1.85-based back end).


Comments on any of these issues and proposed changes, or anything else
anyone has spotted in the recent changes, are welcome...

Ken