#49296 Binded ldapsearch hitting administrative limit for anonymoys rule.
Closed: fixed 8 months ago by ldiedrich. Opened a year ago by ldiedrich.

Issue Description

When trying to execute an ldapsearch with my custom administrative user(binded search), which has its own nslooktroughlimit setted to -1 its return "Administrative Limit" error.

After the help from mreynolds we discovered that it was hitting the Administrative limit from anonymous-limit:

dn: cn=anonymous-limits,cn=etc,dc=domain
nslookthroughlimit: 5000

I changed it to 10000 and the search passed.

My own database has about 7500 users, my custom ldap search should return 529 users.
unila is my domain,
consultaldp is my custom user.

Package Version and Platform

389-ds-base-libs-1.3.5.15-1.fc25.x86_64
389-ds-base-1.3.5.15-1.fc25.x86_64
-
freeipa-server-4.4.3-2.fc25.x86_64
freeipa-server-common-4.4.3-2.fc25.noarch
freeipa-client-4.4.3-2.fc25.x86_64

Steps to reproduce

  1. Have a database with more than 7500 users.
  2. Have a custom user with nslooktroughlimit set with -1
  3. Search the database for something with read all users is database.
  4. Get "Administrative Limit" error.

Actual results

search result

search: 2
result: 11 Administrative limit exceeded

Expected results

search result

search: 2
result: 0 Success

numResponses: 555

numEntries: 554


Metadata Update from @mreynolds:
- Custom field type adjusted to defect
- Issue set to the milestone: 1.3.7.0

a year ago

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.

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field version adjusted to None
- Issue close_status updated to: worksforme
- Issue status updated to: Closed (was: Open)

a year ago

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

Metadata Update from @mreynolds:
- Issue status updated to: Open (was: Closed)

8 months ago

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

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

8 months ago

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

0001-Ticket-49296-Fix-race-condition-in-connection-code-w.patch

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: None)

8 months ago

fixed typos in commit message

0001-Ticket-49296-Fix-race-condition-in-connection-code-w.patch

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,

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1515190
- Issue set to the milestone: 1.3.6.0 (was: 1.3.7.0)

8 months ago

Metadata Update from @mreynolds:
- Custom field rhbz reset (from https://bugzilla.redhat.com/show_bug.cgi?id=1515190)
- Issue set to the milestone: 1.3.7.0 (was: 1.3.6.0)

8 months ago

Much happier! Ack from me :)

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to ack (was: review)

8 months ago

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

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue set to the milestone: 1.3.6.0 (was: 1.3.7.0)
- Issue status updated to: Closed (was: Open)

8 months ago

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1515190

8 months ago

Login to comment on this ticket.

Metadata