replay cache proposal

[Jeffrey Altman]

Pitrich, Karl wrote:

> Hi,
> 
> I encounter problems with the replay cache on the client side
> while using a SPNEGO auth module for apache.
> 
> The replay cache, per default, gets persisted in files.
> Under heavy load, the replay cache runs out of FD's ('to many open
> files').
> 
> Further, when using multiple kerberized Webservices on one machine
> for concurrent access by one webclient(user), the replay cache becomes
> effective, because it is system global, which is IMHO not correct
> default behaviour.
> 
> IMHO it would be better to make the replay cache configurable at runtime
> via environment variable (KRB_RC_INMEMORY).
> 
> 
> If you concur to this proposal, I'll submit a patch shortly.
> 
> 
> greetings,
> 
>  / Karl

Karl:

While an in-memory replay cache certainly does have some potential uses,
the replay cache must be able to survive the restart of a process or the
system.  It is important that when the web server is restarted that it
not suddenly become vulnerable to replay attacks.

It is also important that if there are multiple processes running that
are all sharing the same service principal (e.g. host/fqdn at REALM) that
they all have access to the same replay cache.

That being said, are you sure the problem with running out of file
descriptors is specific to the replay cache?  I have often found that
Linux systems are configured with too few file descriptors when running
Apache.  I most often saw the problem with database access from Apache.
 Tuning the system is often necessary.

Jeffrey Altman





-- 
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu