[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.
Love
PGP signature