[1438] in Kerberos-V5-bugs
Re: krb5_recvauth()
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Jun 1 00:32:40 1995
Date: Thu, 1 Jun 1995 00:22:20 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Ed Phillips <flaregun@udel.edu>
Cc: kerberos@MIT.EDU, krb5-bugs@MIT.EDU
In-Reply-To: Ed Phillips's message of Wed, 31 May 1995 17:24:38 -0400 (EDT),
<Pine.SOL.3.91.950531170258.5174A-100000@strauss.udel.edu>
No, the replay cache *shouldn't be part of the krb5_context, because an
application may be accepting authentications as multiple services, and
you need a separate replay cache for each server principal.
Furthermore, you do have to keep the reply cache in disk, because
multiple processes may need to access the same reply cache
simultaneously. So the requirement to load in the entire rcache, add
entries to it, and saving it back, is always going to be a requirement.
That's why you need to do file locking on the rcache.
Inter-thread locking on the replay cache is potentially a problem;
unfortunately, since I don't want to put any thread specific code in the
Kerberos library (since thread packages are not compatible at the binary
link level --- many aren't even compatible at the source level, POSIX
not withstanding), this means that the application has to be responsible
for doing its own locking around operations which may need to affect the
replay cache.
The other way to fix this would be in threaded enviroments, to replace
krb5_lock_file and krb5_unlock_file with routines that lock the file not
only against other processes, but against other threads too. (In my
opinion, flock() should have done this; to do otherwise violates the
principal of least surprise, and requires that you put knowledge of
threads in libraries that otherwise wouldn't have needed to have
knowledge of threads. But I won't be the first to claim that POSIX
threads are wedged in various different ways....)
Bottom line --- associating the replay cache with the auth_context is
the right thing. The fact that it's not being properly freed (and thus
causing a memory leak) is a problem, which we will address. But don't
expect the fundamental architecture here to change.
- Ted
