getpwnam LDAP cache problem

[mandog]

We run Debian Sarge, our current account script:

1. Uses getpwnam to check if an account exists
2. If not, adds account info to LDAP
3. Uses getpwnam to get the $uid and $gid to chown mail spool

While the script is running, the second getpwnam fails. This behavior does not occur with file (/etc/passwd) based accounts.

The problem also occurs with User::pwent

If it turns out that this isn't a problem with my understanding, I can think of a few (ugly) ways to work around the problem. If it is a real problem, any thoughts on the best way to report the bug to the OpenLDAP (?) Pam (?) glibc (?) people would be helpful.

#!/usr/bin/perl -w

getpwnam("test")
        or warn "account doesn't exist yet... (expected)";

# code to add LDAP account here brings out problem
# code to add to /etc/passwd account doesn't

getpwnam("test")
        or warn "shouldn't see this but we do\n $!";

(system("chown test.test /tmp/file")==0)
or warn "this also fails" 

# this works but is ugly
warn `getent passwd  | grep test`,"\n";

# $! eq 'No such file or directory'

[sgifford]

nscd(8) says:

Nscd provides cacheing for the passwd(5) ... databases through standard libc interfaces, such as getpwnam(3), getpwuid(3), ... and others. Each cache has a separate TTL (time-to-live) for its data; modifying the local database (/etc/passwd, and so forth) causes the cache to become invalidated within fifteen seconds.

So one possibility is that after changing the LDAP directory, waiting 15 seconds will give you the right data. Another possibility is that touching /etc/passwd (or another file configured in nscd.conf) after making the change will cause the cache to be invalidated, at least after 15 seconds.

You could also consider getting the UID directly from LDAP.

And, the reason your run of getent avoids the cache is that it doesn't call getpwnam or getpwuid, but instead goes through the entire passwd database, probably with getpwent. You could probably get the same effect without running a seperate utility by just calling that function repeatedly from within Perl.

It looks like you can control how long nscd caches data in /etc/nscd.conf; see nscd.conf(5).

As to whether it's a bug, that depends on what you expect from your system. Caching is a trade-off of speed for accuracy; if you don't want that trade-off, you can avoid running nscd, or configure it for very short timeouts.

[mandog]

Thank you sgifford ! or perhaps should I say sgifford

nscd does indeed seem to be the "problem" When I apt-get install nscd on a non LDAPified system, the "problem" begins to occur.

An interesting bit, getent does actually seem to be going to the LDAP directory --at least it is listing things that aren't in /etc/passwd

For what it is worth, We'll probably be talking directly to the LDAP directory for our getpwnam purposes. Caching is a "feature" for 86370 seconds in our day.