[1808] in Kerberos_V5_Development
Re: Krb5 Ccache DLL proposal
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Sep 26 22:07:18 1996
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: mikec@geek.grf.ov.com, harryc@cam.ov.com, pbh@MIT.EDU, krbdev@MIT.EDU,
dosdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 26 Sep 1996 22:06:48 -0400
In-Reply-To: "Theodore Y. Ts'o"'s message of Thu, 26 Sep 1996 19:17:41 -0400
Is there a reason for this to be different from the UNIX krb5 library
ccache interface structure, aside from naming and macro-vs-function
and the like?
> typedef struct _cc_keyblock {
> cc_int32 enctype;
> int length;
> unsigned char FAR *contents;
> } krb5_keyblock;
You mean cc_keyblock, I think?
> 1) CC_BADNAME "Bad format of credential cache"
"Bad format of credential cache NAME", if that's what you mean.
> cc_lock(void *handle)
> cc_unlock(void *handle)
How about a cc_trylock, or cc_lock_with_timeout? I'd like to see
either or both in the UNIX library as well.
> It is not necessary to lock or unlock a credential cache before
> reading or modifying the ccache. If the credentials cache is
> unlocked, ccache primitives should lock and unlock the credentials
> cache upon entry and exit. If the application will be doing many
> credentials cache operations, however, it will be more efficient to
> call cc_lock() and cc_unlock().
As long as it's cheap to determine "is this ccache locked and do I own
the lock". Is the latter part going to be cheap enough on all systems
(assuming we're not talking strictly about Windows, and keeping
multi-threaded applications in mind) that there would be no point in
providing alternate cc_foo_locked versions of the other functions?
(Aside: The "do I own the lock" bit won't work in our current UNIX
code with a multi-threaded application. It uses file locking, which
is per-process. So the process would have to keep an in-memory global
list of (locked) ccaches and which threads are locking them.)
