[36162] in Kerberos
Re: krb5-1.12.1 and client keytab file
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri May 30 14:08:29 2014
Message-ID: <5388C914.8020404@mit.edu>
Date: Fri, 30 May 2014 14:08:20 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: "squidmobile@fastmail.fm" <squidmobile@fastmail.fm>, kerberos@mit.edu
In-Reply-To: <1401471523.14490.123388637.5718E167@webmail.messagingengine.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 05/30/2014 01:38 PM, squidmobile@fastmail.fm wrote:
> the bad news is that it did not always work quite as expected.
All of the behaviors you describe are intended, but they could probably
be documented better.
> KRB5CCNAME=MEMORY: KRB5_CLIENT_KTNAME=some.key.file \
> app-with-gssapi-calls
> this worked extemely well. no clashes occured with any other tgt,
> with either the FILE:... or DIR:... syntax.
You might want to give the memory ccache a name (MEMORY:mycache),
although I guess the empty name works too.
> however, i believe
> some dialects of unix make all of memory available via things like
> /dev/kmem or /proc/core, which could pose security issues...
Not a concern. Your process's memory is at least as secure as the files
it reads from.
> one other thought: what happens to app-with-gssapi-calls if it
> runs past the time limit for the tgt obtained by this mechanism?
The KRB5_CLIENT_KTNAME mechanism will renew the TGT when it is halfway
to expired. So if you get ten-hour tickets by default, the resulting
connection should be valid for at least five hours, if the application
even checks.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
