[24017] in Kerberos
RE: replay cache proposal
daemon@ATHENA.MIT.EDU (Johannes russek)
Sat Jun 4 09:42:05 2005
From: "Johannes russek" <johannes.russek@io-consulting.net>
To: "Jeffrey Altman" <jaltman2@nyc.rr.com>
Date: Sat, 4 Jun 2005 15:39:23 +0200
Message-ID: <LGEOIPCNDMCLNENHDMKPGEDICOAA.johannes.russek@io-consulting.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <pK89e.7775$n93.6809@twister.nyc.rr.com>
cc: "Kerberos@Mit. Edu" <kerberos@mit.edu>
Errors-To: kerberos-bounces@mit.edu
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 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
cache :)
do you have any ideas who to blame?
regards, johannes
> -----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
>
> 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
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
