Difference between revisions of "Projects/Keytab ccache name parameters"

Revision as of 10:20, 19 July 2012

This project is to make it possible for a build or configuration of krb5 to change the location of the default keytab, client keytab, and ccache using parameterized search lists.

Background

libkrb5 provides the concepts of the default ccache, default keytab, and default client keytab for a library context. (The default client keytab is new in 1.11; see Projects/Keytab_initiation.) The user-visible discovery mechanisms for these concepts at the moment are:

• The KRB5CCNAME, KRB5_KTNAME, and KRB5_CLIENT_KTNAME environment variables
• The default_keytab_name and default_client_keytab_name profile relations (there is no equivalent for the default ccache)
• On Windows, registry settings for the default ccache
• On Windows, the hardcoded default %TEMP%\krb5cc or %TMP%\krb5cc or {windir}\krb5cc for the default ccache, {windir}\krb5kt for the default keytab, and {windir}\krb5clientkt for the default client keytab.
• On Unix, the hardcoded default /tmp/krb5cc_{uid} for the default ccache, /etc/krb5.keytab for the default keytab, and /etc/krb5.client-keytab for the default client keytab

There are two main problems with the current state of affairs:

• If a collection of daemon processes are running as different uids and need to use different keytabs or client keytabs, they must currently use environment variables in order to do so, which is unwieldy on some operating systems.

• The use of a shared temporary area for the default ccache on Unix systems carries inherent security risks relative to using a per-user temporary area (if the operating system supplies one). Although the login system can override this default by setting KRB5CCNAME, tickets obtained using kinit on a system without Kerberos login integration will use the per-uid default in /tmp.

Requirements

• It must be possible for a group of processes, each running under a different UID, to use distinct keytabs and distinct client keytabs without each setting the KRB5_KTNAME or KRB5_CLIENT_KTNAME environment variables.

• It should be possible for an operating system to gracefully migrate away from the use of /tmp for the default ccache.

• It should be possible to determine the default locations used by a build of krb5 from within a shell script.

• By default, a build of krb5 should use the same default ccache and keytab locations as the current system installation of krb5, if the system installation is new enough to report that information.

Design

The design of this project involves two building blocks (parameter expansion and search lists) and changes to the profile relations, build configuration, and krb5-config scripts.

Parameter expansion

We will adapt the Heimdal expand_path.c facility for our code. This facility supports the following parameter expansions:

•  %{APPDATA} -- Windows roaming application data directory for current user
•  %{COMMON_APPDATA} -- Windows application data directory for all users
•  %{LOCAL_APPDATA} -- Windows local application data directory for current user
•  %{SYSTEM} -- Windows system folder
•  %{WINDOWS} -- Windows folder
•  %{USERCONFIG} -- Windows per-user package config directory
•  %{COMMONCONFIG} -- Windows package config directory for all users
•  %{LIBDIR} -- Package library install directory
•  %{BINDIR} -- Package binary install directory
•  %{LIBEXEC} -- Package internal binary install directory
•  %{SBINDIR} -- Package root binary install directory
•  %{TEMP} -- Temporary directory (e.g. /tmp)
•  %{USERID} or %{uid} -- Current uid (or string representation of Windows SID)
•  %{null} -- Empty string

Not all of these expansions are needed for the current purpose, but it makes sense to support them for consistency.

Search lists

We will create a facility for searching an ordered list of default keytab or ccache names. The intended semantics are:

• Use the first value which exists
• If no value exists, use the first value which we can create
• If no value can be created, use the first value

To make this work, we need new vtable functions for "exists" and "can be created". These vtable functions will operate on the residual part of the name rather than on ccache or keytab handles, since ccache or keytab resolution can cause have side effects for some types.

To test whether filesystem-based ccaches and keytabs exist, we will use stat(). To test whether they can be created, we will use access(). Using access() has the unfortunate property of using the real UID for access control checks for a setuid program, but there isn't a great alternative.

Profile changes

default_keytab_name and default_client_keytab_name will be modified to perform parameter expansion on their values. They will also support multiple values (by setting the variable multiple times), in which case the list of values will be searched as specified above.

A new variable default_ccache_name will be added, with the same semantics as above. It will be used if there is no KRB5CCNAME environment variable setting, and in preference to the build-time default.

krb5-config additions

The krb5-config script will be augmented to support --defccname, --defktname, and --defclientktname options. (TBD: format?)

Build configuration additions

TBD

Testing

TBD

Documentation

TBD

Mailing list discussions

http://mailman.mit.edu/pipermail/krbdev/2012-June/010907.html http://mailman.mit.edu/pipermail/krbdev/2012-June/010959.html

Release notes

TBD