[19943] in Kerberos_V5_Development
Re: gss_store_cred_into() and gss_acquire_cred_from() on a client
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri May 24 14:07:40 2019
To: moore moore <moore_chestnut@yahoo.ie>, "krbdev@mit.edu" <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <cb6a0fe0-a7ed-7150-9367-f839a1cf3f3b@mit.edu>
Date: Fri, 24 May 2019 14:07:18 -0400
MIME-Version: 1.0
In-Reply-To: <2102456337.9036239.1558714753967@mail.yahoo.com>
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On 5/24/19 12:19 PM, moore moore wrote:
> gss_acquire_cred_from() for gss_name:u:clientuser1@TEST.COM,
> store:0x6ddf68, elem:0x6ddf78
>
> [28197] 1558713187.312227: Retrieving clientuser1@TEST.COM from
> FILE:/krb5/dest/var/krb5/user/0/client.keytab (vno 0, enctype 0) with
> result: 2/Key table file '/krb5/dest/var/krb5/user/0/client.keytab' not
> found
Oh, I see, it's the only trace log message. It seems we don't generate
any trace logs when scanning the ccache, so there's nothing in the trace
log to verify what ccache gss_acquire_cred_from() is trying to use.
Since the trace logs aren't helpful in this case, I would suggest adding
debugging code to verify what values are contained within store, not
just that it has the same pointer value. If you're in a position to
step through the libgssapi_krb5 code, you could alternatively see what's
happening inside scan_ccache().
Separately, it occurs to me that if the same process is handling the
reauths, you could just save the GSS cred handle and not bother with
gss_store_cred_into/gss_acquire_cred_from. You'd have to create your
own table mapping client names to GSS cred handles to make this work,
but there would be fewer GSS and krb5 operations to worry about. Just
another option.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
