Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred()

[Simo Sorce <[e-mail]>]

On Thu, 2015-03-19 at 12:33 -0500, Nico Williams wrote:
> On Thu, Mar 19, 2015 at 01:04:46PM -0400, Simo Sorce wrote:
> > Would you consider an explicitly set KRB5CCNAME env variable as an
> > indication the admin is ok with acquired credentials ending up there ?
> > Ie a) but using KRB5CCNAME presence as an indication a ccache can be
> > used ?
> 
> That helps, though there can still be non-determinism when the ccache
> does not exist yet.  (But if the admin/user set it, why wouldn't they
> also kinit -k to remove all doubt?)

Because, at least with the current implementation of the Keytab
initiation feature in MIT, if you kinit explicitly then
gss_init_sec_context will not take over and keep initiating when
credentials expires etc...

I understand this may be simply an implementation issue/bug and it can
be decided differently, but in general keytab initiation is used to
allow unattended systems work on their own, so the admin will start a
service with all the evn var set right and let it to it's own thing,
requiring to script a manual kinit would defeat the purpose.

So I am trying to see if you think a) is compatible with something
priming an empty initial ccache provided that both KRB5CCNAME and
KRB5_CLIENT_KTNAME have been set in the environment (both required).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York