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

[Jeffrey Altman <[e-mail]>]

On 3/19/2015 1:44 PM, Simo Sorce wrote:
> 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,

I would be more comfortable with an environment variable or krb5.conf
option that explicitly states to perform X behavior.  The existence of
environment variables that are useful on their own in combination should
not should trigger an unexpected behavior.  Especially when those
environment variables are interpreted different by different Kerberos
distributions.

Just my two cents ...

Jeffrey Altman