logo_kerberos.gif

Difference between revisions of "Projects/Database Access Layer cleanup"

From K5Wiki
Jump to: navigation, search
(db_invoke)
(Miscellaneous cleanup)
Line 37: Line 37:
 
The db_put_principal function takes a list of krb5_db_entry structures. We never use it to put more than one principal, and we have no expectation of needing transactional updates across principals. It should take only a single krb5_db_entry.
 
The db_put_principal function takes a list of krb5_db_entry structures. We never use it to put more than one principal, and we have no expectation of needing transactional updates across principals. It should take only a single krb5_db_entry.
   
Some krb5_db functions are never used. Since we have no compatibility promises for libkdb across releases, these should be inventoried and removed.
+
Some krb5_db functions are never used, such as krb5_db_set_option. Since we have no compatibility promises for libkdb across releases, these should be inventoried and removed.
  +
  +
There are two different "not supported" error codes used by krb5_db. The LDAP plugin mostly returns KRB5_PLUGIN_OP_NOTSUPP (except in db_invoke), while kdb5.h and hdb use KRB5_KDB_DBTYPE_NOSUP. kdb5_util dump expects to see KRB5_PLUGIN_OP_NOTSUPP from a database which does not support locks. These error codes should be collapsed into one.

Revision as of 18:53, 21 January 2010

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


This project page describes ideas for cleaning up the KDB Database Access Layer (DAL). No resources or schedule have been assigned to this project yet. It is likely that this project will be narrowed or split out into sub-projects before implementation.

Master key encryption

DB2 and LDAP encrypt key entries in a master key, which is obtained either through password entry at KDC/kadmind startup time or from a stash file. Encryption and decryption of key data is currently performed explicitly in the KDC and libkadm5.

It is possible to construct a database plugin which does not encrypt key data in a master key, but it is hackish: the plugin overrides the default fetch_master_key function to return a dummy key, and overrides the default dbekd_encrypt_key_data and dbekd_decrypt_key_data functions to perform no encryption or decryption.

It would perhaps be cleaner if key encryption and decryption were performed underneath the DAL. Since the user interface features associated with master keys necessarily exist above the DAL, we would still need entry points to implement those features.

Jump points (db_set_option and db_invoke)

The functions db_set_option and db_invoke accept a method number and arguments (a void * for db_set_option, and a pair of krb5_data objects for db_invoke) whose interpretation depends on the method number. They are each used for a variety of unrelated purposes.

Both functions should be split out into separate, type-safe interfaces; there is no good reason to combine multiple unrelated operations into a single vtable pointer.

tl_data

The krb5_db_entry structure contains a field named tl_data, which was originally introduced in order to make the DB2 back end extensible.

The TL-data concept should exist below the DAL, and the krb5_db_entry structure should contain the actual fields represented in TL-data.

krb5_key_data

The krb5_key_data structure is very representation-oriented. It contains a "version" (separate from the kvno) which indicates whether or not there is an explicit salt associated with the key, and then the type/length/contents pointers are arrays of two elements, the second of which determines the explicit salt. This structure should be redefined in a more logical fashion, and the conversion to the format used by the DB2 back end should be performed underneath the DAL.

Alias-related flags

The flags field for db_get_principal does not explicitly indicate whether aliases are okay. (They should be allowed for TGS requests, and for AS requests if the client indicates a willingness to accept them.) Currently the LDAP back end uses a combination of CLIENT_REFERRALS_ONLY and CANONICALIZE to decide whether to return aliases. There should be an explicit flag.

Miscellaneous cleanup

The db_get_principal function takes "nentries" and "more" parameters which are never productively used. A principal name can only have one associated principal.

The db_put_principal function takes a list of krb5_db_entry structures. We never use it to put more than one principal, and we have no expectation of needing transactional updates across principals. It should take only a single krb5_db_entry.

Some krb5_db functions are never used, such as krb5_db_set_option. Since we have no compatibility promises for libkdb across releases, these should be inventoried and removed.

There are two different "not supported" error codes used by krb5_db. The LDAP plugin mostly returns KRB5_PLUGIN_OP_NOTSUPP (except in db_invoke), while kdb5.h and hdb use KRB5_KDB_DBTYPE_NOSUP. kdb5_util dump expects to see KRB5_PLUGIN_OP_NOTSUPP from a database which does not support locks. These error codes should be collapsed into one.