This is a discussion on RE: replay cache proposal - Kerberos ; hi guys, i'm running into the same problem with saslauthd using pam_krb5. after a while it stops working, because it opens /tmp/rc_host_0 a few thousand times and runs into the "too many open files" case. while it might be the ...
i'm running into the same problem with saslauthd using pam_krb5. after a
while it stops working, because it opens /tmp/rc_host_0 a few thousand times
and runs into the "too many open files" case.
while it might be the badly configured environment, it seems that saslauthd,
pam_krb5 or any of the underlying libraries is opening the replay cache, but
not closing it after a successful auth session. so it *must* run into the
situation of having too many open files, because it never closes the replay
do you have any ideas who to blame?
> -----Original Message-----
> From: kerberos-bounces@MIT.EDU [mailto:kerberos-bounces@MIT.EDU]On
> Behalf Of Jeffrey Altman
> Sent: Tuesday, April 19, 2005 4:39 PM
> To: kerberos@MIT.EDU
> Subject: Re: replay cache proposal
> 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
> 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@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
> Kerberos mailing list Kerberos@mit.edu
Kerberos mailing list Kerberos@mit.edu