[OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT

[Marcus Watts]

openafs rxk5 (at least as it exists today) looks for an
	AFS_RXK5_DEFAULT
environment variable which interacts with
command line options to determine whether
it uses rxk5 or rxkad.  Most commands have these options:
	-ktc -k4 -k5 -localauth -noauth
which determine which security mechanism is used and
where the credentials originate.  Following are some notes
on how these interact:

if AFS_RXK5_DEFAULT is
not set
	klog, aklog
		will attempt to get tickets for
			afs-k5/<cellname>	rxk5
			afs/<cellname>		rxkad
			afs			rxkad
		in that order
	commands -localauth
		commands will look for keytab
				rxk5
		then keyfile
				rxkad
		(-k4, -k5 force use of keyfile or keytab)
	commands
		"-ktc" behavior by default:
		get ticket from kernel, use rxk5 or rxkad as appropriate.
		(-k5 force use of k5cc, rxk5.)
0 "do k4"
	klog, aklog
		will attempt to get tickets for
			afs/<cellname>		rxkad
			afs			rxkad
		in that order
	commands -localauth
		default to -k4: commands will look for keyfile
				rxkad
		(-k5 force use of keyfile or keytab)
	commands
		"-ktc" behavior by default:
		get ticket from kernel, use rxk5 or rxkad as appropriate.
		(-k5 force use of k5cc, rxk5.)
1 "k5 + ktc"
	klog, aklog
		will attempt to get tickets for
			afs-k5/<cellname>	rxk5
		in that order
	commands -localauth
		default to -k5: commands will look for keytab
			rxk5
		(-k4 force use of keyfile)
	commands
		"-ktc" behavior by default:
		get ticket from kernel, use rxk5 or rxkad as appropriate.
		(-k5 force use of k5cc, rxk5.)
2 "pure k5"
	klog, aklog
		will attempt to get tickets for
			afs-k5/<cellname>	rxk5
		in that order
	commands -localauth
		default to -k5: commands will look for keytab
			rxk5
		(-k4 force use of keyfile)
	commands
		"-k5" behavior by default:
		get ticket from k5 cc, use rxk5.
		("-ktc" behavior, get ticket from kernel, rxkad or rxk5)

krb5.conf note.
For proper aklog operation, it has always been important to
get "[domain_realm]" right; these must be capable of resolving
all afsdb machines into the proper k5 realm.  aklog has also
always provided options to override this behavior.  There may
be many sites that are used to using those options and have
not got "[domain_realm]" right.  For operation with the k5cc
above (AFS_RXK5_DEFAULT=2 or most commands with -k5), it
is critical that "[domain_realm]" be right.  Most commands
provide no explicit mechanism to override this on the
command line.  It is of course possible to set KRB5_CONFIG
and point it to a custom krb5.conf that sets this.

Binaries that are transported to a non-rxk5 machine:
k5 options will not be effective.
k4 options will work.  Binaries will fall back to "legacy"
token interface if new "generic" token interface is
not present.

non-rxk5 machines include
non-rxk5 patched code
	will only support legacy token interface:
rxk5 patched code
	support new "generic" token interface for rxkad only,
	as well as legacy token interface.
	"capability" cm call, with no data.
rxk5 machines will support
	support new "generic" token interface for rxk5 and rxkad.
	legacy token interface for old binaries or source
	"capability" cm call, with rxk5 encryption types.

The intention is that the "generic" token interface be capable
of being augmented with with future token types (such as rxgk) in
the future.  The assumption is that in a given realm,
all db & file servers be capable of dealing with the same
credential type, and that is the responsibility of aklog/klog,
with input from the user & from the kdc, to get the appropriate
credential.  The "capability" call is intended to return
information on cm capabilities.  For now it only supports
rxk5 encryption types.  In the future, it might also return
information on other things, or have a companion pioctl
to allow setting things.  This might be used to get/set
locking behavior or fs setcrypt.

			-Marcus Watts