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

[Simo Sorce <[e-mail]>]

On Thu, 2015-03-19 at 10:17 -0500, Nico Williams wrote:
> On Thu, Mar 19, 2015 at 09:32:14AM -0400, Simo Sorce wrote:
> > On Tue, 2015-03-10 at 19:18 -0500, Nico Williams wrote:
> > > I can see three principles:
> > > 
> > > a) no side-effects outside caching,
> > > b) idempotent side-effects only,
> > > c) what principles?  anything goes.
> > 
> > I tend to agree with you in abstract, however given b) is the actual,
> > and I would say expected in many cases, behavior, I do not't think we
> > can retroactively mandate a), but b) should be good enough.
> 
> ISTR hearing someone (you?) say (a couple of weeks ago on a krbdev call)
> that creating a default ccache with one of N > 1 principals' keytab
> creds is sometimes surprising to users, and I can see why it would be!
> This is a form of (b).  The problem here is setting the default
> principal name when none had already been set -- a non-trivial side-effect.
> 
> I'm inclined to consider (b) a bug.  A low-priority bug perhaps, but a bug.
> 
> Implementations could do something else.  E.g., not cache (thus increasing
> load on clients and KDCs), or cache in a "shadow default ccache", or
> switch to DIR ccache.  Those are details.  The main thing is that (b) is
> surprising.

I guess it may be surprising in some cases, and expected in others,
unfortunately.
If you set the KRB5_CLIENT_KTNAME variable in recent MIT releases you
expect a default ccache to be created with whatever is in the keytab for
example. But you'd be surprised otherwise.

Simo.

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