Projects/Keytab ccache name parameters

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 is targeted at release 1.11.

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

TBD

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

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