KRB5ENVVAR(7) Standards, Environments, and Macros KRB5ENVVAR(7)
NAME
krb5envvar - Kerberos environment variables
DESCRIPTION
The Kerberos mechanism provides a number of environment variables to
configure different behavior in order to meet applications' needs.
Environment variables used within the Kerberos mechanism are:
KRB5_KTNAME Used by the mechanism to specify the location of the key table file.
The variable can be set to the following value:
[[
<kt type>:]
<file name>]
where
<kt type> can be
FILE or
WRFILE.
FILE is for read operations;
WRFILE is for write operations.
<file name> is the location of the
keytab file.
r
If
KRB5_KTNAME is not defined, the default value is:
FILE:/etc/krb5/krb5.keytab
The
keytab file is used to store credentials persistently and is used
commonly for service daemons.
Specifying the
FILE type assumes that the subsequent operations on
the associated file are readable by the invoking process. Care must
be taken to ensure that the file is readable only by the set of
principals that need to retrieve their unencrypted keys.
The
WRFILE type is used by the
kadmin(8) command. Specifying this
type allows the administrator to designate an alternate
keytab file
to write to without using extra command line arguments for file
location.
KRB5CCNAME Used by the mechanism to specify the location of the credential
cache. The variable can be set to the following value:
[[
<cc type>:]
<file name>]
where
<cc type> can be
FILE or
MEMORY.
<file name> is the location of
the principal's credential cache.
If
KRB5CCNAME is not defined, the default value is:
FILE:/tmp/krb5cc_
<uid> where
<uid> is the user id of the process that created the cache
file.
The credential cache file is used to store tickets that have been
granted to the principal.
Specifying the
FILE types assumes that subsequent operations on the
associated file are readable and writable by the invoking process.
Care must be taken to ensure that the file is accessible only by the
set of principals that need to access their credentials. If the
credential file is in a directory to which other users have write
access, you need to set that directory's sticky bit (see
chmod(1)).
The
MEMORY credential cache type is used only in special cases, such
as when making a temporary cache for the life of the invoking
process.
KRB5RCNAME Used by the mechanism to specify the type and location of the replay
cache. The variable can be set to the following value:
[[
<rc type>:]
<file name>]
where
<rc type> can be either
FILE,
MEMORY, or
NONE.
<file name> is
relevant only when specifying the replay cache file type.
If not defined, the default value is:
FILE:/var/krb5/rcache/root/rc_
<service> ...if the process is owned by root, or:
FILE:/var/krb5/rcache/rc_
<service> ...if the process is owned by a user other than root.
<service> is
the service process name associated with the replay cache file.
The replay cache is used by Kerberos to detect the replay of
authentication data. This prevents people who capture authentication
messages on the network from authenticating to the server by
resending these messages.
When specifying the
FILE replay cache type, care must be taken to
prevent the replay cache file from being deleted by another user.
Make sure that every directory in the replay cache path is either
writable only by the owner of the replay cache or that the sticky bit
("
t") is set on every directory in the replay cache path to which
others have write permission.
When specifying the
MEMORY replay cache type you need to weigh the
trade-off of performance against the slight security risk created by
using a non-persistent cache. The risk occurs during system reboots
when the following condition obtains:
o The duration from the last write to the replay cache
before reboot to the point when the Kerberized server
applications are running is less than the Kerberos
clockskew (see
krb5.conf(5)).
When specifying the
NONE replay cache time you need to understand
that this disables the replay cache, and all security risks that this
presents. This includes all the risks outlined in this section of the
man page.
Under this condition, the server applications can accept a replay of
Kerberos authentication data (up to the difference between the time
of the last write and the clockskew). Typically, this is a small
window of time. If the server applications take longer than the
clockskew to start accepting connections there is no replay risk.
The risk described above is the same when using
FILE replay cache
types when the replay cache resides on swap file systems, such as
/tmp and
/var/run.
The performance improvement in
MEMORY replay cache types over
FILE types is derived from the absence of disk I/O. This is true even if
the
FILE replay cache is on a memory-backed file system, such as swap
(
/tmp and
/var/run).
Note that
MEMORY-type caches are per-process caches, therefore use
of these types of caches must be carefully considered. One example
of where
MEMORY-type caches can be problematic is when an
application uses more than one process for establishing security
contexts. In such a case, memory replay caches are not shared across
the processes, thus allowing potential for replay attacks.
KRB5_CONFIG Allows you to change the default location of the
/etc/krb5/krb5.conf file to enable the Kerberos library code to read configuration
parameters from another file specified by KRB5_CONFIG. For example
(using kinit from
ksh(1)):
KRB5_CONFIG=/var/tmp/krb5.conf kinit
ATTRIBUTES
See
attributes(7) for a description of the following attributes:
+--------------------+-----------------+
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
+--------------------+-----------------+
|Interface Stability | Uncommitted |
+--------------------+-----------------+
SEE ALSO
chmod(1),
kinit(1),
klist(1),
ksh(1),
krb5.conf(5),
attributes(7),
kerberos(7),
kadmin(8),
kadmind(8) February 13, 2008
KRB5ENVVAR(7)