鍵テーブルファイルの場所を指定するためのメカニズムで使用されます。この変数には、次の値を設定できます:

[[<kt type>:]<file name>]

ここで、<kt type> には FILE または WRFILE を指定できます。FILE は読み取り操作用、WRFILE は書き込み操作用です。<file name> は、keytab ファイルの場所です。 r KRB5_KTNAME が定義されない場合のデフォルト値は次のとおりです:

FILE:/etc/krb5/krb5.keytab

keytab ファイルは、永続的に資格を格納するために使用され、一般にサービスデーモンで使用されます。 FILE タイプを指定することは、関連するファイル上の後続操作が呼び出しプロセスで読み取り可能であることが前提となっています。暗号化されていない鍵を取得する必要のある主体のセットでのみファイルが読み取り可能になるように注意してください。 WRFILE タイプは、kadmin(1M) コマンドで使用されます。このタイプを指定すると、管理者は追加のコマンド行引数を使用してファイルの場所を指定しなくても、書き込む代替の keytab ファイルを指定できます。

資格キャッシュの場所を指定するためのメカニズムで使用されます。この変数には、次の値を設定できます:

[[<cc type>:]<file name>]

ここで、<cc type> には FILE または MEMORY を指定できます。<file name> は主体の資格キャッシュの場所です。 KRB5CCNAME が定義されない場合のデフォルト値は次のとおりです:

FILE:/tmp/krb5cc_<uid>

ここで、<uid> はキャッシュファイルを作成したプロセスのユーザー ID です。 資格キャッシュファイルは、主体に付与されているチケットを格納するために使用されます。 FILE タイプを指定することは、関連するファイル上の後続操作が呼び出しプロセスで読み書き可能であることが前提となっています。資格にアクセスする必要のある主体のセットのみがファイルにアクセス可能になるように注意してください。ほかのユーザーが書き込みアクセス権を持っているディレクトリ内に資格ファイルがある場合、そのディレクトリのスティッキービットを設定する必要があります (chmod(1) を参照)。 MEMORY タイプの資格キャッシュは、呼び出しプロセスの存続期間中に一時キャッシュを作成する場合などの特殊なケースでしか使用されません。

リプレイキャッシュのタイプと場所を指定するためのメカニズムで使用されます。この変数には、次の値を設定できます:

[[<rc type>:]<file name>]

ここで、<rc type> には FILE、MEMORY、または NONE を指定できます。<file name> が関連するのは、リプレイキャッシュファイルタイプを指定する場合のみです。 定義されない場合のデフォルト値は次のとおりです:

FILE:/var/krb5/rcache/root/rc_<service>

root がプロセスを所有している場合、または:

FILE:/var/krb5/rcache/rc_<service>

root 以外のユーザーがプロセスを所有している場合。<service> は、リプレイキャッシュファイルに関連付けられたサービスプロセス名です。 リプレイキャッシュは、Kerberos で認証データのリプレイを検出する際に使用されます。これにより、ネットワーク上の認証メッセージを取得するユーザーは、これらのメッセージを再送信しても、サーバーに対する認証を行なうことができません。 FILE タイプのリプレイキャッシュを指定する場合は、別のユーザーがリプレイキャッシュファイルを削除できないように注意してください。リプレイキャッシュの所有者のみがリプレイキャッシュパスのすべてのディレクトリに書き込み可能であるか、またはその他のユーザーが書き込み権を持っているリプレイキャッシュパスのすべてのディレクトリにスティッキービット (" t") が設定されていることを確認します。 MEMORY タイプのリプレイキャッシュを指定する場合は、非永続性キャッシュを使用することで発生するわずかなセキュリティーリスクに対するパフォーマンスのトレードオフを比較検討する必要があります。次の状況になると、システムのリブート中にリスクが発生します: NONE リプレイキャッシュ時間を指定する場合は、これによりリプレイキャッシュが無効になることと、発生するすべてのセキュリティーリスクについて理解する必要があります。これには、マニュアルページの該当セクションで説明されたすべてのリスクが含まれます。 このような状況では、サーバーアプリケーションは、Kerberos 認証データのリプレイを (最後の書き込み時間とクロックスキューとの差異まで) 許容できます。一般に、これは短い猶予時間です。接続の受け入れを開始するまでの時間がクロックスキューよりもサーバーアプリケーションの方が長い場合は、リプレイのリスクはありません。 前述のリスクは、/var/run や /tmp などのスワップファイルシステム上にリプレイキャッシュが存在するときに、FILE タイプのリプレイキャッシュを使用する場合と同じです。 MEMORY タイプのリプレイキャッシュでは、ディスク I/O が存在しないことによって、FILE タイプよりもパフォーマンスが改善されています。このことは、FILE リプレイキャッシュがスワップ (/tmp や /var/run など) のメモリーに基づくファイルシステムに存在する場合でも該当します。 MEMORY タイプのキャッシュはプロセスごとのキャッシュであるため、これらのタイプのキャッシュを使用する際には十分に考慮する必要があります。MEMORY タイプのキャッシュで問題が発生する可能性がある一例として、セキュリティーコンテキストを確立するために複数のプロセスがアプリケーションで使用されている場合があります。このような場合、リプレイキャッシュメモリーはプロセス間で共有されないため、リプレイ攻撃の可能性があります。

KRB5_CONFIG で指定された別のファイルから構成パラメータを Kerberos ライブラリコードで読み取ることができるように、/etc/krb5/krb5.conf ファイルのデフォルトの場所を変更できます。ksh(1) から kinit を使用する例:

 KRB5_CONFIG=/var/tmp/krb5.conf kinit