gssd: Allow GSSAPI to try to acquire credentials first.

gssd: Allow GSSAPI to try to acquire credentials first.

GSSAPI can be given a uid number as a special name, and then
gss_acquire_cred() can use the name to try to find credentials for
the user.

Give GSSAPI a chance to do it on its own, then fallback to the classic
method of trolling through the file system to find a credential cache.

This patch uses a little know feature of GSSAPI that permits to acquire
crdentials specifying the user's UID. Normally GSSAPI will simply
perform a getpwuid() call and use the user name to generate a principal name and
then see if it can find a TGT for that principal in the local ccache.

This feature is vital to allow the GSS-Proxy to be able to initiate
crdentials on behalf of rpc.gssd using client keytabs stored in the filsystem.

GSS-Proxy works through an interposer-type plugin (new feature in MIT 1.11)
that allows to intercept all GSSAPI requestes and relay them to a system
daemon via a socket. This daemon (GSS-Proxy) then can perform operations
on behalf of other applications with additional logic.

In the rpc.gssd case the GSS-Proxy daemon allows applications running as
system users to properly access krb5 protected shares by creating a
credential cache on the fly when necessary.

This way all applications that need access to krb5 protected shares do not need
to be taught how to initiate crdentials on their own, nor they need to be
wrapped in additional init scripts like k5start or use wasteful cronjobs to
keep credentials fresh. All is needed is to drop a keytab with the right keys
in a special location on the system and gss-proxy will do the rest.

Signed-off-by: Simo Sorce <simo@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>