Cleanups

This page describes opportunities for internal code cleanups. Anything to do with a user-facing or developer-facing behavior should go elsewhere (perhaps in an RT ticket, or somewhere related to the roadmap).

• sam2_process (preauth_sam2.c) should use a cleanup label instead of repeated free invocations. It is also long and should be broken up into smaller pieces if possible. (See Manual Testing for guidance on how to test at least part of this function.)

• kadmind's main() should not have repeated blocks of calls to release resources. It's probably unnecessary to release resources on error exit (plenty of other programs don't bother).

• k5-utf.8 uses its own conditionals for fixed-length types instead of the ones from krb5.h. On a related note, ucdata.h uses krb5_ui_4 instead of krb5_ucs4 but callers in ucstr.c use krb5_ucs4 pointers, generating warnings.

• The build system used to have multiple configure.in files making use of an aclocal.m4. Now that we only have one configure.in, we don't really need a separate aclocal.m4.

• Not all variables in the build system's Makefile fragments (like pre.in) are used. For instance, SHLIB_TAIL_COMP and KRB5_SHLIBDIR appear to be unused. Some variables like INSTALL_PREFIX are just name variants of other variables and are only used in one or two places under the variant name.

• Account lockout decision logic is duplicated in the DB2 and LDAP KDB modules.

• The serialization framework has several levels of unnecessary nesting. Also, it passes every serialization call through a table lookup of magic numbers, which is unnecessary since we always know what we're serializing (except for krb5_serialize_data, which is not used outside of test programs and is not a public API despite the name).

• lib/krb5/os appears to have a couple of different functions to generate ADDRTYPE_ADDRPORT addresses (one in mkfaddr.c and another in full_ipaddr.c).

• klist and kinit (at least) still have some internal vestiges from when they supported krb4 and krb5 credentials, and could be simplified.

• The kdcpreauth pluggable interface uses the new plugin support functions, but does not have a proper consumer interface as described in Projects/Plugin_support_improvements#Consumer_interface.

• kdc_preauth.c could be simplified by simply inserting informational padata values into the returned sequence, rather than having fake preauth systems for each informational preauth type.

• It's no longer our practice to use krb5_xfree() instead of free(), but it's still used in a few places (kdb5.c and the LDAP KDB module).

• It's no longer our practice to use krb5_x() to make calls through function pointers, but it's still used in a few places (ktfns.c and rcfns.c).

• Some kdc_util.c functions take krb5_db_entry structures instead of pointers.

• The LDAP KDB module maintains a connection pool, but only ever uses one connection (since our KDC is single-threaded).

• krb5_rc_default and krb5_rc_default_name are not part of our public API and are not used in the tree.

• Various parts of lib/gssapi still use K&R-style function definitions.

• lib/gssapi/mechglue should use the MIT krb5 style, not the Solaris coding style with tabs.

• lib/gssapi/generic contains some utility functions which are specific to the krb5 mech and should be located in lib/gssapi/krb5.

• Some parameters in osconf.hin are unused (like KDC_PORTNAME and KDC_SECONDARY_PORTNAME), or appear to be used but are never really used (like KRB5_DEFAULT_ADMIN_ACL and DEFAULT_ADMIN_ACL).

• kpropd's design can be simplified:
  • Currently, it forks to handle each incoming connection, but then waits for the child process. This could be done without forking, although doit() would have to be modified to avoid using exit() or an aborting SIGALRM handler.
  • Currently kpropd relies on dual-stack support to handle both IPv4 and IPv6 connections so that it can use a single blocking accept() call to wait for incoming connections. Some platforms such as OpenBSD don't have dual-stack support. We should open a listening socket for each address family and use libverto to wait for connections on both of them.
  • Currently, if iprop is enabled, a child process is used to handle incoming connections, but using libverto, the same process should be able to handle both. The process wouldn't ask for iprop updates while processing a kprop connection (since that handling is synchronous), but that should be okay.

• The libkdb5 interface includes krb5_db_setup_lib_handle(), which has no caller-visible semantics (it is invoked internally when needed). That function can be removed from the interface, since we don't guarantee interface stability for that library.

• krb5_db_get_age() and its associated DAL interface can be removed.

• The krb5_db_entry "len" field has no caller-useful semantics. krb5_db_put_principal will abort with the DB2 back end if the len field is not set to the magic value KRB5_KDB_V1_BASE_LENGTH. This field and the associated constant can be removed.

• The krb5_db_entry "n_tl_data" field is redundant with the length of the tl_data linked list, and isn't likely to have a significant performance impact since tl_data lists are short. It can be removed.

• The constants KRB5_TL_KADM5_E_DATA, KRB5_TL_RB1_CHALLENGE, KRB5_TL_USER_CERTIFICATE, KRB5_TL_LM_KEY, and KRB5_TL_X509_SUBJECT_ISSUER_NAME are unused and can likely be removed.

• The osa_policy_ent_rec "version" field has no caller-visible semantics; it is used internally by the DB2 module's xdr_osa_policy_ent_rec(), but a local variable would serve. The field can be removed.

• krb5_db_iter_policy takes a match_expr parameter and passes it through to the back end, but both back ends ignore it. The parameter can be removed.

• We have two implementations of reading realm parameters, one used by the KDC (krb5_read_realm_params) and the other used by everything else (kadm5_get_config_params). realm_params contains five parameters which overlap with config_params and seven which do not. We could combine the implementations, or we could reject the notion of consolidated realm parameters and provide individual accessors for each parameter (but note that kadm5_config_params doubles as a container for various kadm5_init_* parameters). Combining the implementations is complicated by different handling of three overlapping fields:
  • enctype: config_params assigns a default of DEFAULT_KDC_ENCTYPE. realm_params assigns no default. The KDC assigns a default based on a command-line argument for manual master key entry, which defaults to des-cbc-crc.
  • max_life: config_params assigns a default of one day. realm_params assigns no default. The KDC assigns a default of KRB5_KDB_MAX_LIFE, which is also one day.
  • max_rlife: config_params assigns a default of 0. realm_params assigns no default. The KDC assigns a default of KRB5_KDB_MAX_RLIFE, which is

seven days.