oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

Pluggable libheimbase interface for DBs and misc libheimbase enhancements

Browse Source 
[Code reviewed by Love Hörnquist Åstrand <lha@kth.se>]

    Added heim_db_*() entry points for dealing with databases, and
    make krb5_aname_to_localname() use it.

    The following enhancements to libheimbase are included:

     - Add heim_data_t and heim_string_t "reference" variants to
       avoid memory copies of potentially large data/strings.

       See heim_data_ref_create() and heim_string_ref_create().

     - Added enhancements to heim_array_t to allow their use for
       queues and stacks, and to improve performance.  See
       heim_array_insert_value().

     - Added XPath-like accessors for heim_object_t.  See
       heim_path_get(), heim_path_copy(), heim_path_create(), and
       heim_path_delete().  These are used extensively in the DB
       framework's generic composition of ACID support and in the
       test_base program

     - Made libheimbase more consistent with Core Foundation naming
       conventions.  See heim_{dict, array}_{get, copy}_value() and
       heim_path_{get, copy}().

     - Added functionality to and fixed bugs in base/json.c:
        - heim_serialize();
        - depth limit for JSON parsing (for DoS protection);
        - pretty-printing;
        - JSON compliance (see below);
        - flag options for parsing and serializing; these are needed
          because of impedance mismatches between heim_object_t and
          JSON (e.g., heim_dict_t allows non-string keys, but JSON
          does not; heimbase supports binary data, while JSON does
          not).

     - Added heim_error_enomem().

     - Enhanced the test_base program to test new functionality and
       to use heim_path*() to better test JSON encoding.  This
       includes some fuzz testing of JSON parsing, and running the
       test under valgrind.

     - Started to add doxygen documentation for libheimbase (but doc
       build for libheimbase is still incomplete).

    Note that there's still some incomplete JSON support:

     - JSON string quoting is not fully implemented;

     - libheimbase lacks support for real numbers, while JSON has
       it -- otherwise libheimbase is a superset of JSON,
       specifically in that any heim_object_t can be a key for an
       associative array.

    The following DB backends are supported natively:

     - "sorted-text", a binary search of sorted (in C locale), flat
       text files;

     - "json", a backend that stores DB contents serialized as JSON
       (this is intended for configuration-like contents).

    The DB framework supports:

     - multiple key/value tables per-DB
     - ACID transactions

    The DB framework also natively implements ACID transactions for
    any DB backends that a) do not provide transactions natively, b)
    do provide lock/unlock/sync methods (even on Windows).  This
    includes autocommit of DB updates outside transactions.

    Future DB enhancements may include:

     - add backends for various DB types (BDB, CDB, MDB, ...);

     - make libhdb use heim_db_t;

     - add a command-line tool for interfacing to databases via
       libheimbase (e.g., to get/set/delete values, create/copy/
       backup DBs, inspect history, check integrity);

     - framework-level transaction logging (with redo and undo
       logging), for generic incremental replication;

     - framework-level DB integrity checking.

       We could store a MAC of the XOR of a hash function applied to
       {key, value} for every entry in the DB, then use this to check
       DB integrity incrementally during incremental replication, as
       well as for the whole DB.
This commit is contained in:
Nicolas Williams
2011-12-29 01:29:26 -06:00
parent df73c96b74
commit f4ba41ebdd
30 changed files with 4211 additions and 259 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
lib/krb5/krb5-plugin.7
View File

@@ -41,6 +41,7 @@
.In krb5.h
.In krb5/an2ln_plugin.h
.In krb5/ccache_plugin.h
.In krb5/db_plugin.h
.In krb5/kuserok_plugin.h
.In krb5/locate_plugin.h
.In krb5/send_to_kdc_plugin.h
@@ -48,8 +49,8 @@
Heimdal has a plugin interface. Plugins may be statically linked into
Heimdal and registered via the
.Xr krb5_plugin_register 3
function, or they may be loaded from shared objects present in the
Heimdal plugins directories.
function, or they may be dynamically loaded from shared objects present
in the Heimdal plugins directories.
.Pp
Plugins consist of a C struct whose struct name is given in the
associated header file, such as, for example,
@@ -57,7 +58,7 @@ associated header file, such as, for example,
and a pointer to which is either registered via
.Xr krb5_plugin_register 3
or found in a shared object via a symbol lookup for the symbol name
defined in the associated header file (e.g., "kuserok-plugin" for the
defined in the associated header file (e.g., "kuserok" for the
plugin for
.Xr krb5_kuserok 3
).
@@ -81,16 +82,26 @@ be output through the init function's second argument.
plugin's context to be destroyed, and returning void.
.El
.Pp
Each plugin type must add one or more fields to this struct following
the above three. Plugins are typically invoked in no particular order until
one succeeds or fails, or all return a special return value such as
KRB5_PLUGIN_NO_HANDLE to indicate that the plugin was not applicable. Most
plugin types obtain deterministic plugin behavior in spite of the
non-deterministic invokation order by, for example, invoking all plugins for
each "rule" and passing the rule to each plugin with the expectation that just
one plugin will match any given rule.
Each plugin type must add zero or more fields to this struct following
the above three. Plugins are typically invoked in no particular order
until one succeeds or fails, or all return a special return value such
as KRB5_PLUGIN_NO_HANDLE to indicate that the plugin was not applicable.
Most plugin types obtain deterministic plugin behavior in spite of the
non-deterministic invokation order by, for example, invoking all plugins
for each "rule" and passing the rule to each plugin with the expectation
that just one plugin will match any given rule.
.Pp
The krb5-kuserok plugin adds a single field to its struct: a pointer to
There is a database plugin system intended for many of the uses of
databases in Heimdal. The plugin is expected to call
.Xr heim_db_register 3
from its
.Va init
entry point to register a DB type. The DB plugin's
.Va fini
function must do nothing, and the plugin must not provide any other
entry points.
.Pp
The krb5_kuserok plugin adds a single field to its struct: a pointer to
a function that implements kuserok functionality with the following
form:
.Bd -literal -offset indent