Implement SRXGK_AFSCombineTokens

This functionality requires a way for the vlserver to be able to lookup
the token-encrypting key for a given fileserver UUID.  To do this from
the rx security class directly would be a layering violation; rxgk
cannot depend on the vlserver directly.  Instead, supply a callback
as service-specific data, which gives a routine to retrieve a key
for encrypting tokens to a given UUID.

No implementations of this getfskey hook are provided in this commit;
the vlserver's implementation will come in a later commit.

Change-Id: Icd955202c92a3665e1e827b81687e17a2a28638d
Build rxgk support into libafsrpc

This is done rather differently for the shared and static libafsrpc
forms.  For the shared library, we can add a dependency on the shared
$(GSSAPI_LIBS) and link in liboafs_rxgk.la directly.  libafsrpc_rxgk.la
(which only has stubs for the rxgk GSS-using routines) is linked into
the static library, so that it remains useful for statically linking
applications.  Consumers of libafsrpc.a need not be modified in
accordance with this change.

Change-Id: I76c0329ba842fb0d4d66534810b114a0813c90a0
BuildServerSecurityObjects allocate for rxgk

Don't do anything with it for now, just leave a place in the
array.

Change-Id: I304e0f6bcf7d3b2a2cb46c976f41e09809a436db
Let superuser identities be superusers

We have a special rx_identity_kind for superusers, let it actually
be useful for something.

Change-Id: I1d551ed8e5fcfd6bdc29c6c27eee4c2ae67e1a89
Add rxgk support to userok

Sprinkle @RXGK_LIBS_STATIC@ as needed to keep LWP bits building.

Change-Id: I5da2a89532453b6bec61fc87218a61455e39f6f0
Implement afsconf_GetRXGKKey

Also afsconf_GetLatestRXGKKey, as a side effect, since we want to have
a single getkey function both for getting encrypting and decrypting keys;
a kvno/enctype pair of 0/0 indicates that the "get latest" behavior is
desired.

Implement both functions in terms of an internal helper that takes
as an argument the type of key to look for in the KeyFileExt.  We
can reuse these helpers wholesale for per-fileserver keys, later.

This also requires implementing an ordering on the quality of the
different RFC 3961 enctypes (which are stored as the subtype of keys
of type afsconf_rxgk).  This is ... pretty awkward to code up, and
also subject to debate on the actual ordering.  Since the IANA enctype
registry changes rarely, just assign a full ordering on the standardized
(symmetric!) enctypes, giving integers as the ordered values, and
store that in a constant array.  Then, the lookup table allows the
comparison of the strength of enctypes ~directly.

Provide stubs for KERNEL use; UKERNEL builds this file but does not
have any real rxgk support yet, so fails to link due to the
missing rxgk_make_key symbol.

Sprinkle some @RXGK_LIBS_STATIC@ to keep the LWP bits building and
add the corresponding dependencies on @RXGK_TARGET@.

Change-Id: I81389b21238fd6588cc4381b026816005f81a30c
Add afsconf_BuildUbikServerSecurityObjects

This new interface is specifically for use in building the server
security objects that will be used to handle ubik-internal connections
(that is, DISK_ and VOTE_).

This is the normaml set from BuildServerSecurityObjects, with a custom
rxgk server security object.  The only tokens used for ubik-internal
communication are printed tokens, so the rxgk key negotiation service
(RXGK_) should not be provided.  afsconf_GetRXGKKey is used as the
getkey function for these connections, since the cell-wide rxgk key
from KeyFileExt is used for them.

Change-Id: Id332aabcf80ed35bda36dcce92e762d46b590f47
Use afsconf_BuildUbikServerSecurityObjects for vl, ptserver

Accept rxgk tokens for incoming intra-ubik connections.

Change-Id: I31dca8c8db4dada1a5d3f9b193e7506fdf6ece47
Add afsconf_BuildDbServerSecurityObjects

Used to build the server security objects for database servers that
will accept the actual user RPCs (for the VL and PR services, etc.).
Since these security objects will be used to handle
RXGK_AFSCombineTokens requests, allow a callback to be supplied that
can be used to look up the fileserver long-term key used to encrypt
fileserver tokens.

Change-Id: I59e6bce2c1ccf8c873bda913b28f26d9c2a49f63
Use afsconf_BuildDbServerSecurityObjects for the vl, ptserver

Change-Id: I713d78384f4d6347b17104a97ad72650ac363491
Add afsconf_ClientAuthRXGK

Always encrypts, eliminating the need for a separate 'Secure' variant.
On modern hardware the AES we'll end up doing should be faster than
our rx stack can keep up with.

Change-Id: Ib27f2799eb927ac5aa71eab94212171344dd93df
Add -rxgk option to vlserver, ptserver

Optionally use rxgk for ubik server-to-server connections, via
afsconf_ClientAuthRXGK.  All the db servers in the cell must have
been upgraded to a version that accepts rxgk ubik connections before
this option can safely be enabled.

Change-Id: Iefae46291330d2b5e05b2a2bbaec1b9150b3c892
Add afsconf getkey variants for RXGKFS

That is, getkey routines for use by fileservers.

Fileservers will keep their token-encrypting keys in KeyFileExt,
using a new key type afsconf_rxgk_fs.  Such keys are only used
if no keys of type afsconf_rxgk are present (that is, the cell-wide
key takes precedence, both at token-decyryption time and at
vlserver-registration time).

Also fix some whitespace nits where the KeyFileExt key types
are defined.

Change-Id: Ife585cc976ffe1b1f86d9f285f3be9e599c75c29
Add afsconf_BuildFileServerSecurityObjects

Make use of the new getkey routines for per-fileserver keys, but
only if there are no cell-wide keys available.

Change-Id: I0cd3b7c5654c113f18c0a49c6e7bd84b2b5edfb7
vlserver: use an rxgk getfskey routine

In order for SRXGK_AFSCombineTokens to function properly, the rx
service providing that RPC must attach service-specific data
allowing the lookup of a token-encrypting key for a given fileserver
UUID.  This commit provides a very simple implementation of that
getfskey functionality for the vlserver.

In particular, it only supports fileservers that have the shared
cell-wide key, and only fileservers that are colocated with
database servers.  This is because it is required for a database
server to have the cell-wide key for operation, and so a fileserver
on that same host must also have access to the cell-wide key.
Since no released version of this software has database servers that
implement rxgk but fileservers that do not implement rxgk, if
rxgk is enabled, we can assume that the fileserver software supports
rxgk and has access to the shared cell-wide key.

This is the best functionality that can be supplied reliably
without changes to the vldb format (which would mark whether
individual file servers are rxgk-capable, and what key to use
for them).

Change-Id: I6f7afe34c2ec5e99e7b1b3984a92d1dda6eda2de
Supply kernel variants of rxgk_int generated files

Add the extra calls to rxgen.

Change-Id: I06b333de48e694fc85ff25961874b683cec1625f
Data types for in-kernel rxgk tokens

We will only be able to use the GetTokens2 and SetTokens2 variants,
which use XDR to encode/decode data across the pioctl boundary.
Since userspace only needs to use these types immediatly around pioctl,
it can use the XDR-produced types directly, but these data types are
rather clunky for regular use in the kernel.

As such, define additional types for use in the kernel, as is done
for the existing rxkad functionality.

The XDR types for pioctl use should only be used for dbserver
tokens; userland should not be acquiring fileserver tokens for
kernel use, and the kernel should not be caching fileserver tokens
where they might get returned to userland.  This allows us to
preserve the invariant that a TokenJar has only one token per
user per cell per token type.

In order to make the XDR types for rxgk tokens dependent on the
configure option --enable-rxgk, we must include afsconfig.h in
token.xg for use by rxgen's preprocessor.  This requires some
tweaks to work everywhere, since afsconfig.h can bring in sys/types.h,
which on some systems has typedefs that are not compatible with
RPC-L typedefs.
In-kernel pioctl handlers for rxgk tokens

Use the new data types to implement functionality for using
rxgk tokens with GetTokens2 and SetTokens2.  The structure is
basically parallel to the existing rxkad handling.

Change-Id: I1089488bbb26fa56bd6d6b011b2c4b62beaf912d
Add gklog; insert rxgk tokens into the kernel

This is mostly a stub implementation with very minimal
functionality.  All of the nice things that aklog provides
(log to paths, log to multiple cells, .xlog, etc.) are not
supported; this is just a way to do functionality testing
at the moment.

Keep the old copyright from the aklog code this started from, and
update the date for the new work.  (Same rightsholder, imagine that.)

Ideally it would be possible to factor out most of aklog into
something that can be reused for rxgk, but that is probably a
fair amount of work.

Change-Id: I83c9a6b5646dcbaa692df535ba3965b8b4309f2d
tokens: display rxgk tokens

Pretty minimal output, for now.  The rxgkTime expiration
time is not converted to a more human-friendly format.

We do not currently store anywhere on the client the client's
GSSAPI identity which is embedded in the token, so it is
only possible to print the viceid (if present) for now.

Change-Id: If79b919e64e47ae79a966a2df6a5b0f898bff6db