context negotiation performance problem

[Ken Raeburn]

On Nov 2, 2005, at 16:03, Eric Mei wrote:
> I searched archive but didn't find the answer.
>
> I made a simple test for security context negotiation of MIT  
> krb5-1.3.5, under Linux, driven by GSSAPI: client call  
> gss_init_sec_context() and send token to server, server call  
> gss_accept_sec_context() and send back the result token.
>
> on a P4 1.6G machine, the server only could handle ~10 requests per  
> second, and there's lots of disk I/O during running. By strace, I  
> found krb5 libraries created a temp file under "/var/tmp", and call  
> following syscalls for each request:
>    write(fd, data, 50);
>    fsync(fd);
> The fsync() certainly lead to low performance. Anybody know why it  
> is here?

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.)

> Besides the fsync(), vmstat shows ~200 blocks write per seconds. It  
> seems the above "write(fd, data, 50)" can't produce that much data.  
> So where those write come from? Are there any other known issue  
> might affect performance?

Doesn't ring a bell offhand...

> Our server might experience 1000s of context negotiation requests  
> at the same time, so the above performance problem looks serious to  
> us.

Is this a single-process server, or multiple processes?  Multiple  
processes would probably deal better with the fsync calls.

Ken