[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: krb5 cc iteration and selection functions

Alexandra Ellwood <lxs@MIT.EDU> writes:

>> So adding the restriction that the credential cache return must be
>> valid
>> and adding a krb5_promp function pointer (and assosited pointer)
>> will solve
>> your concern ? If the promper function is NULL, the call failes if
>> it can't
>> find a matching credentail.
> No I don't think the function should prompt.  That would be outside the
> scope of behavior of the krb5_cc_* functions.  I'm not even sure if it
> should check for validity since the other krb5_cc_* functions don't know
> anything about the meaning of the fields in the creds structure.

So if I just drop the _cc from the name, it would be fine ? Right now its
implemented using krb5_cc function and really don't need to know anything
about the existing krb5_cc internals now that I've add those other krb5_cc
cache iteration functions.

> Back when we were coming up with the CCAPI we always had to fight the
> desire to make the CCAPI smarter (ie: having the CCacheServer auto-renew,
> etc).  Invariably we decided against these features because they add
> complexity and break the abstraction barrier between the data storage
> layer and the libraries that use it.  In the long run I think our
> attitude has helped keep the CCAPI manageable both from code maintenance
> and security standpoints.

I'm not sure if I agree with this in the sense that I think the
functionallity should exists, and having more processes running doesn't
make the system less complex and hard to manage.


PGP signature