Ken Raeburn wrote:
That's almost certainly the replay cache file, meant to prevent the
re-use of a transmitted authenticator by an attacker. The fsync is
there to handle the problem of the machine crashing or losing power
after an authenticator has been accepted and a data exchange
performed, but the on-disk cache not yet updated.
If your protocol or threat model is such that replay attacks are not
a problem, then under later versions of the code (I'd check whether
it's in the 1.4 series, but the machine where I keep my source trees
checked out ate its root file system over the weekend) you could set
the environment variable KRB5RCACHETYPE to "none" before starting the
program. (Look for src/lib/krb5/rcache/rc_none.c to see if you've
got the support.)
Is this a single-process server, or multiple processes? Multiple
processes would probably deal better with the fsync calls.
Thanks a lot Ken. 1.4.2 indeed support KRB5RCACHETYPE=none. I enable it
and rewrite the test as multi-processes. Now the server could handle at
least 600/s now.
Thanks again!
Eric
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
