Bug 150748 - nscd cache does not expire its caches?
nscd cache does not expire its caches?
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
Blocks: 164812
  Show dependency treegraph
Reported: 2005-03-10 02:00 EST by Frank Mueller
Modified: 2007-11-30 17:11 EST (History)
9 users (show)

See Also:
Fixed In Version: 2.3.5-4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-25 13:05:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Frank Mueller 2005-03-10 02:00:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Description of problem:
After changing the password on our NIS-Server, the client does not use the new password while nscd is active. With deactivated nscd the new passwords are delivered. Restarting nscd gives again the old password. Timeouts in /etc/nscd.conf are the default values (600 sec), but I get the old password even after 3 days

Version-Release number of selected component (if applicable):
glibc-2.3.4-2.fc3  nscd-2.3.4-2.fc3

How reproducible:

Steps to Reproduce:
1. Change password on NIS Server
2. wait 30 min
3. getent passwd user
4. getent passwd | grep user

Actual Results:  "getent passwd user" gives me the old password hash, while nscd is active
"getent passwd|grep user" gives me the new hash, same for "ypcat passwd"

Expected Results:  After the 10 minutes timeout I expect to se the new hash values

Additional info:

No information about any problems in /var/log/messages

Output from nscd -d -d -d:

12368: Access Vector Cache (AVC) started
12368: handle_request: request received (Version = 2) from PID 12376
12368:  GETFDPW
12368: provide access to FD 5, for passwd
Comment 1 Hans Deragon 2005-03-22 10:17:40 EST
On FC3, I suffer of the same symptoms, but with hostnames.  It returns old
invalid IPs when resolving hostnames and the cache never gets updated.  This
happens with the same version reported above.

nscd simply does not update its cache anymore.
Comment 2 Aleksey Nogin 2005-03-25 08:25:20 EST
Just got bitten by stale entries in nscd's hostname cache (FC3). This can lead
to a numer of pretty bad problems, so I am increasing the severity.
Comment 3 Pekka Pietikäinen 2005-04-14 08:09:48 EDT
I'm seeing this too. Was just going to post to fedora-test-list. It seems caches
only get flushed when the files get touched, and not when the TTL has expired.

Here's the post:

We've been seeing nscd cache expiration problems every now and then
like I mentioned a few months back with both passwd and hosts. Has
happened often enough that it's not just a local configuration issue

It seems like positive hits just don't time out, and nscd -i is the only
thing that clears things up. passwd/hosts "never" get touched (we're using
NIS+, customized local install), so the entries don't get invalidated that
way, which might be the reason not that many other people are seeing the
same problem. Another symptom I've sometimes seen is a DDNS host
have an old address for days (until nscd -i hosts). nslookup,
which doesn't go through nscd, shows the current address.
nscd is running with default timeouts (600 secs for passwd, 3600 for hosts)

Will be happy to get data to track this down. I suppose there's no
database dumper that would tell what nscd is actually currently caching and
how old the data is?

I've actually ran nscd for quite some time in debug mode, and the only
situation it flushes entries is touch /etc/passwd and touch /etc/hosts.
Comment 4 Nicolas Troncoso Carrere 2005-04-20 18:36:16 EDT
At our lab we have the same issue. We are using LDAP authentication, user tend
to change their passwords, and try to access their mail trough IMAP, the imap
server uses the NSCD cache, and oops failed.

As discused in an erlier thread this is a disign issue, nscd was never tought to
be use in this fasion.

We have been able to control this trhough the configuration file. We reduce the
lifetime of the hash tables, set the caches to be NON persisten. (that is right,
no matter how many times you restart the service the cache does not flush unless
this option is enabled.), and set the service to auto restart every 10 minutes.

The overall preformance does not seem to be afected.

Comment 5 Mark J. Cox (Product Security) 2005-04-22 03:11:59 EDT
This bug has been raised to secalert@redhat.com as having possible security
consequences due to stale DNS/auth/etc.  
Comment 7 Ulrich Drepper 2005-04-28 02:29:40 EDT
I checked into the upstream cvs a patch which might cure this problem.  I don't
know whether this is the case since nobody bothered to provide debug output.
Hopefully we'll have a new rawhide version soon.
Comment 8 Jakub Jelinek 2005-04-28 08:37:09 EDT
nscd-2.3.5-4 has this fix in.
Comment 9 Aleksey Nogin 2005-04-28 13:16:22 EDT
Any chance for an FC3 errata?
Comment 10 WhidbeyNet 2005-06-02 11:32:14 EDT
Still no RHEL update over a month after nscd fix was found.  We're beginning to
doubt weither maintaining our "Enterprise" subscriptions is really worthwhile,
compared to Fedora. What's stability without security and bug fixes?
Comment 11 Jakub Jelinek 2005-06-02 11:43:50 EDT
This bug fix is scheduled for RHEL4 U2, it came too late to be included in RHEL4
Comment 12 Jack Neely 2005-06-06 16:33:48 EDT
Is a rawhide RPM with this fix that will be included in U2 available somewhere?
Comment 13 Pekka Pietikäinen 2005-06-07 02:27:56 EDT
I'm happily using rawhide/FC4's nscd (only, not the other bits of glibc) on FC3,
since an errata update doesn't seem to be coming any time soon for FC3 either.
You might have luck on RHEL as well. Since the default nscd is pretty much
unusable if you are hitting this bug it's unlikely it's going to make things any
worse :-)
Comment 14 Jakub Jelinek 2005-06-07 10:41:34 EDT
The rawhide/FC4 rpms will not be included in RHEL4 U2.  Instead, the patch
(among other fixes collected for U2) will be backported.

If you want to rebuild glibc yourself, the fix is:

Running FC4/rawhide nscd on RHEL4 could work too.
Comment 15 Jakub Jelinek 2005-07-06 13:16:47 EDT
RHEL4 U2 initial glibc testing RPMs that should address also this problem
uploaded to ftp://people.redhat.com/jakub/glibc/2.3.4-2.10/
Comment 18 Josh Smith 2005-07-25 13:02:27 EDT
According to comment #8, this fix has been in rawhide for three months now, but
still now FC 3 update. What's the status?
Comment 19 Jakub Jelinek 2005-07-25 13:05:25 EDT
It is in FC3 testing updates ATM.
Comment 21 Josh Smith 2005-08-29 14:59:13 EDT
This ticket is listed as closed, but there's still no FC 3 update. Is this ever
going to come out of rawhide?
Comment 22 Josh Smith 2005-10-06 16:00:36 EDT
Just got another update saying that a clone of this bug (BugID 164812) was
fixed... But there's still no FC 3 update. I suppose FC 3 will simply become
unsupported soon, and be forgotten entirely.

Note You need to log in before you can comment on or make changes to this bug.