Allow libtool symbol files in the objdir

Check if a .sym file is present in the build directory; if so, use it.
Otherwise, fall back to the srcdir copy as we always have.

Change-Id: I57056b8b8300cd302212c313a3a618d5c9f81c31
rxgk_gss cast some times to 64-bit

Change-Id: Ibdf02675152ccebbabdf3f2ee0cf9244111a5902
Fix leak in rxgk_server

Change-Id: I8d7ca53b2c9b900a77ff652a6bb9397d7bd1621e
Export copy_ids to the rest of rxgk

It will prove convenient to use it in rxgk_procs, I think.

Change-Id: I2e326188a69b0fd7946fb0dd01a7be4bf7f0fee9
rxgk_get_token semantics change

Turns out we need the raw key in order to send it into the kernel...

Change-Id: Ia048b05abe129fa147046e4505c698e0a4ecbbd9
Factor out the core RXGK key-fetching logic

We'll want to reuse that logic for keys of type afsconf_rxgk_fs
shortly.

Change-Id: Ib696ac48c47f67cac453d76baade5b5ffdbbdbf6
Move key-fetching out of combine_tokens_common

Using the getkey function from service-specific data will only
ever get a token-encrypting key for the current service, which
is inappropriate for AFSCombineTokens, in which case the
token-encrypting key may need to be obtained from the VLDB.

Change-Id: Id4fda8157944ad47f4b497f48c60447680e6ca14
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
rxgk support for viced

Use afsconf_BuildFileServerSecurityObjects to get our security
objects; introspect to see if there is an rxgk object in the
output, so that we can use rxgk.

If we have rxgk capability, use an rxgk connection to the vlserver
to register our addresses.  Only printed tokens from the cell-wide
key are currently supported, and we do not support registering
per-fileserver keys.  (For one, the vldb has no way of recording
that we are rxgk-capable yet.)

While here, make a file-local routine static.

The use_rxgk flag should arguably be a part of the configuration
directory state, but that can wait for later.

Change-Id: I067ce991e69cb2b2752e6808573489a0aa4f5e3c
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
Add getfskey argument to BuildDBServerSecurityObjects

Will need to hook this into the server security object somehow,
and this seems the least ugly at the moment.

Change-Id: Ic70ea18ab8eef4b4231c3f3ed68aabe15190111d
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).
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
Note a location where future work is needed

Change-Id: I7590fc5b354aead1373476cea2d2af876b535689
rx: Do not try to cancel nonexistent events

Unconditionally cancelling the resend event and releasing the
reference it was supposed to have on the call, can cause the
call reference count to go negative.

In particular, the call chain when a new rx_call structure is
allocated would cause its reference count to become negative.

Behave similarly to all the other rxevent_Cancel calls touched
by 20034a815750beff262d49b37fba225c72dd0ab1, and only cancel the
event and drop a reference when the event is present on the call.

Change-Id: Icf2dd58c2545814ac17bb960077621c6d3209da0