Reusing UID causes both old and new user to appear in the cache

[jaqx0r]

Original issue 14 created by jaqx0r on 2008-09-15T22:19:41.000Z:

What steps will reproduce the problem?

1. Delete a user from the LDAP directory
2. Create a new user in the directory with the same UID as the user who was deleted
3. Update the cache

What is the expected output? What do you see instead?
Only the new user should appear. However, "getent passwd" will show both users, with the same
UID. I confirmed that deleting the cache and regenerating it from scratch gets rid of the old entry.

What version of the product are you using? On what operating system?
0.8.0 on Gentoo Linux. Apple's Open Directory on OS X 10.5

[jaqx0r]

Comment #1 originally posted by jaqx0r on 2008-09-15T22:41:04.000Z:

I should note that this doesn't occur if I use the --full switch for "nsscache update". Of course, even in
incremental mode, I don't think duplicate entries like this should be possible..

[jaqx0r]

Comment #2 originally posted by jaqx0r on 2009-01-09T00:11:34.000Z:

As Kamil suggested in my discussion thread from yesterday, it appears I'm suffering
from the same issue when a user is deleted from the LDAP directory. When using
partial updates only, deleted entries in the source are not deleted from the local
cache (I suspect they are not being detected at all).

Running 0.8.3 on RHEL5. Source is OpenLDAP 2.3.27 on RHEL5.

[jaqx0r]

Comment #3 originally posted by jaqx0r on 2009-01-11T19:20:16.000Z:

it sounds like this is the case. furthermore since our data maps are stored
internally keyed on username, there is no conflict in holding 2 different usernames
with the same uid.

we could introduce something to catch this, but on an incremental update how would we
handle it? for this case we could evict the "older" entry, and assume the one being
merged in is replacing it.

but this could lead to flip-flopping if the source database actually has conflicting
uids, one uid would disappear on an incremental update where the other was
modified..then it'd come back on a full sync or flop the other way on the next
modification.

all in all, I think this better handled by a clear note in a README or caveat or
something somewhere to explain the bahviour of ldap incremental updates, and
ultimately fixed by something like rfc 4533 where it is supported.

thoughts?

[jaqx0r]

Comment #4 originally posted by jaqx0r on 2009-01-12T17:27:56.000Z:

Good point. The uid is the key in the LDAP database, so it makes sense to key the map on that.

I don't think there's any sense in coding around it, but perhaps nsscache could write a warning to stderr if a
duplicate UID is encountered in the cache? At least this would make it easier to diagnose the problem.

[jaqx0r]

Comment #5 originally posted by jaqx0r on 2014-04-30T13:52:57.000Z:

Technically the DN is the key in the LDAP database, not the UID.

I'm adding a warning if a duplicate key is detected, but this will only warn for duplicate nsscache keys, in this case the username, not the UID.

[jaqx0r]

Comment #6 originally posted by jaqx0r on 2014-04-30T13:58:19.000Z:

This issue was closed by revision c4dc48115972.