I can not reproduce this on 389-ds-base-1.3.6 and up...

This is my setup below and I can do queries returning 40k entries using ldapsearch. if I do an anonymous bind I do hit the limits set in the anonymous resource limit entry. If I do a bind with a user without its own defined limits, the global limits set under cn=config take effect. So everything seems to be working correctly.

dn: cn=config
nsslapd-anonlimitsdn: cn=anon template,dc=example,dc=com

dn: cn=config,cn=ldbm database,cn=plugins,cn=config
nsslapd-lookthroughlimit: 2000

dn: cn=anon template,dc=example,dc=com
nsSizeLimit: 250
nsLookThroughLimit: 1000
nsTimeLimit: 2

dn: uid=mark,dc=example,dc=com
nsTimeLimit: 120
nsLookThroughLimit: -1
nsSizeLimit: -1
nsIdleTimeout: 5000

I'm going to close this ticket, but if you can provide a reproducible testcase/setup for 1.3.6 then please reopen this ticket.

FreeIPA keeps seeing this issue. Reopening for further investigation...

Thanks for re-opening the ticket. Reproduced with FreeIPA 4.6.3-1.fc27, 389-ds-base 1.3.7.9-1.fc27.

In my config, the limits are set as follows:

dn: cn=config
nsslapd-sizelimit: 8888

dn: cn=config,cn=ldbm database,cn=plugins,cn=config
nsslapd-lookthroughlimit: 100000

dn: cn=anonymous-limits,cn=etc,$BASEDN
nsSizeLimit: 5555
nsLookThroughLimit: 5551

The user uid=admin,cn=accounts,cn=users,$BASEDN does not define any limits. ldapsearch output is inconsistent, sometimes returns err=11 (admin limit exceeded) with numEntries=5551, sometimes succeeds (the db contains 6003 user entries):

[root@vm-171-207 ~]# ldapsearch -D uid=admin,cn=users,cn=accounts,$BASEDN -w Secret123 -x -b cn=users,cn=accounts,$BASEDN dn | grep -E "result|numEntries"
# search result
result: 11 Administrative limit exceeded
# numEntries: 5551
[root@vm-171-207 ~]# ldapsearch -D uid=admin,cn=users,cn=accounts,$BASEDN -w Secret123 -x -b cn=users,cn=accounts,$BASEDN dn | grep -E "result|numEntries"
# search result
result: 0 Success
# numEntries: 6003

It appears to be a race condition. If I run a loop of anonymous searches, and do a bind as user , it will occasionally incorrectly pick up the anonymous limits for that user.

Still investigating

Problem was a race condition in the connection code that allowed the anonymous limits to be incorrectly set after the bind op occurred.

fixed typos in commit message

Hey mate,

This doesn't actually fix the issue. :(

The issue is that you don't hold c_mutex on the conn, so the change isn't being propagated correctly into memory.

So this fix only masks the race condition on small systems, but larger cpu systems will still have it.

I think the correct fix requires you to put c_mutex in front of the c_inited value else it may not be synced properly.

(also consider naming it "limits_initialised" instead)

Hope that helps,

Ps: also worth noting it's unsafe to read from a value that protected by a mutex/rwlock without taking said lock. So this whole part of the code has some theoretical unsafety ....

Hey mate,
This doesn't actually fix the issue. :(
The issue is that you don't hold c_mutex on the conn,

So this fix only masks the race condition on small systems, but larger cpu systems will still have it.

Yeah I guess it's possible if the client did an asynchronous bind and asynchronous search at the same time, otherwise I don't think any lock is needed. The fix sets the flag before any other thread "should" access that connection because its happening on a new connection. We have not sent a result to the client yet, so there should not be anything coming in over the pipe that another worker thread would pick up. The flag is never adjusted again during the life of that connection so it "should" be safe to read on all future operations.

I think the asynchronous bind and search combo is very unlikely, but it's possible I guess. I just didn't want to add more locking, and the comments in the code says the lock is not needed. Anyway I'm fine adding the lock though - it shouldn't have too big of an impact on perf.

I think the correct fix requires you to put c_mutex in front of the c_inited value else it may not be synced properly.
(also consider naming it "limits_initialised" instead)

Yeah I changed the name like 3 times before I submitted the patch, I have no problem changing it a 4th time.

Hope that helps,

BZ https://bugzilla.redhat.com/show_bug.cgi?id=1515190 is probably the same issue

Revised patch

Much happier! Ack from me :)

774ee3e..0d5214d master -> master

229f76c..8a3b9f1 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

de82415..3e19256 389-ds-base-1.3.6 -> 389-ds-base-1.3.6

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2355

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.