Bug 1249908 - No validation check for the value for nsslapd-db-locks.
Summary: No validation check for the value for nsslapd-db-locks.
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Depends On:
TreeView+ depends on / blocked
Reported: 2015-08-04 06:45 UTC by Amita Sharma
Modified: 2016-11-03 20:35 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-11-03 20:35:33 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2594 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description Amita Sharma 2015-08-04 06:45:23 UTC
Description of problem:
No validation check for the value for nsslapd-db-locks.

Version-Release number of selected component (if applicable):
[root@dhcp201-167 ~]# rpm -qa | grep 389

How reproducible:

Steps to Reproduce:
1. Stop the server.
2. Modify value for nsslapd-db-configured-locks and set as 0
3. start the server

Actual results:
nsslapd-db-configured-locks takes any value.

Expected results:
A range of value should be accepted and values should be validated.

Additional info:
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1180776 for more information

Comment 3 Noriko Hosoi 2015-08-11 15:50:41 UTC
Upstream ticket:

Comment 5 Noriko Hosoi 2015-12-17 00:53:29 UTC
One correction in the step 2 to reproduce the problem.
2. Modify value for nsslapd-db-configured-locks and set as 0

"nsslapd-db-configured-locks" is not a valid db config param.
It is suppsoed to be "nsslapd-db-locks".
Please note that cn=config,cn=ldbm database,cn=plugins,cn=config is an extensible object, there is no way to reject a garbage param, which is just ignored.

Comment 6 Mike McCune 2016-03-28 23:12:48 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 8 Simon Pichugin 2016-06-14 15:49:24 UTC
Build tested:

Verification steps:
1. Install a directory server instance.

2. Stop the server.
[0 root@host ~]# stop-dirsrv
Stopping instance "host"

3. Modify value for nsslapd-db-locks and set as 10
[0 root@host ~]# sed -i "s/nsslapd-db-locks: 10000/nsslapd-db-locks: 10/g" /etc/dirsrv/slapd-qeos-165/dse.ldif

4. Start the server
[0 root@host ~]# start-dirsrv
Starting instance "host"

5. Check error log for reset message:
[0 root@host ~]# cat /var/log/dirsrv/slapd-host/errors | grep "New max db lock count is too small.  Resetting it to the default value 10000"
[14/Jun/2016:11:32:52.265773093 -0400] New max db lock count is too small.  Resetting it to the default value 10000.

6. Restart server and check dse.ldif for reseted value:
[0 root@host ~]# restart-dirsrv
Restarting instance "host"
[0 root@host ~]# cat /etc/dirsrv/slapd-host/dse.ldif | grep nsslapd-db-locks
nsslapd-db-locks: 10000

Marking as verified.

Comment 10 errata-xmlrpc 2016-11-03 20:35:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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