Bug 1533828 - Server allows to set nsds5replicaid=65535 in the existing replica entry
Summary: Server allows to set nsds5replicaid=65535 in the existing replica entry
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-12 10:31 UTC by Amita Sharma
Modified: 2020-09-13 22:07 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.3.7.5-15
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 14:23:50 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2600 0 None None None 2020-09-13 22:07:29 UTC
Red Hat Product Errata RHBA-2018:0811 0 None None None 2018-04-10 14:24:44 UTC

Description Amita Sharma 2018-01-12 10:31:56 UTC
Description of problem:
We can break the nsds5replicaid attribute rules (it should be 1 to 65534 for masters) if we'll try to modify the existing replication entry.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.7.5-11.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install an instance
2. Add a replica entry:
[root@qeos-19 upstream]# ldapmodify -a -h localhost -p 389 -D "cn=Directory manager" -w Secret123 << EOF
> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
> cn: replica
> nsDS5Flags: 1
> nsDS5ReplicaBindDN: cn=sync user,cn=config
> nsDS5ReplicaId: 65535
> nsDS5ReplicaRoot: dc=example,dc=com
> nsDS5ReplicaType: 3
> objectClass: top
> objectClass: nsDS5Replica
> objectClass: extensibleobject
> EOF
adding new entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"

AND another use case ::

1. Existing MMR 
2. On M1 try ::
[root@qeos-19 upstream]# ldapmodify -h localhost -p 39001 -D "cn=Directory manager" -w password << EOF
> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
> changetype: modify
> replace: nsDS5ReplicaId
> nsDS5ReplicaId: 65535
> EOF
modifying entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"


Actual results: Operation is Successful


Expected results: It should fail with error message ::
ldap_modify: Server is unwilling to perform (53)
	additional info: Attribute nsDS5ReplicaId value (wrong_id) is invalid, must be a number between 1 and 65535.

Additional info:

Comment 3 Amita Sharma 2018-01-12 11:22:07 UTC
It seems bug was introduced by 0025-Ticket-48393-Improve-replication-config-validation.patch ( https://pagure.io/389-ds-base/issue/48393 ) , 
fix for https://bugzilla.redhat.com/show_bug.cgi?id=1271208

I tested it on -6 and -7 to confirm ::
=========================================
[root@qeos-8 upstream]# rpm -qa | grep 389
389-ds-base-libs-1.3.7.5-6.el7.x86_64
389-ds-base-1.3.7.5-6.el7.x86_64
389-ds-base-snmp-1.3.7.5-6.el7.x86_64
[root@qeos-8 upstream]# 

[root@qeos-8 upstream]# ldapmodify -a -h localhost -p 389 -D "cn=Directory manager" -w Secret123 << EOF
> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
> cn: replica
> nsDS5Flags: 1
> nsDS5ReplicaBindDN: cn=sync user,cn=config
> nsDS5ReplicaId: 65535
> nsDS5ReplicaRoot: dc=example,dc=com
> nsDS5ReplicaType: 3
> objectClass: top
> objectClass: nsDS5Replica
> objectClass: extensibleobject
> EOF
adding new entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
ldap_add: Operations error (1)
	additional info: Attribute nsDS5ReplicaId must have a value greater than 0 and less than 65535: entry cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

===============================================================================

[root@qeos-25 upstream]# ldapmodify -a -h localhost -p 389 -D "cn=Directory manager" -w Secret123 << EOF
> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
> cn: replica
> nsDS5Flags: 1
> nsDS5ReplicaBindDN: cn=sync user,cn=config
> nsDS5ReplicaId: 65535
> nsDS5ReplicaRoot: dc=example,dc=com
> nsDS5ReplicaType: 3
> objectClass: top
> objectClass: nsDS5Replica
> objectClass: extensibleobject
> EOF
adding new entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"

[root@qeos-25 upstream]# rpm -qa | grep 389
389-ds-base-libs-1.3.7.5-7.el7.x86_64
389-ds-base-1.3.7.5-7.el7.x86_64
389-ds-base-snmp-1.3.7.5-7.el7.x86_64

Comment 4 mreynolds 2018-01-18 17:45:48 UTC
Upstream ticket:
https://pagure.io/389-ds-base/issue/49541

Comment 6 Amita Sharma 2018-01-29 12:01:17 UTC
This works fine.
[root@qeos-11 upstream]# ldapmodify -a -h localhost -p 389 -D "cn=Directory manager" -w Secret123 << EOF
> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
> cn: replica
> nsDS5Flags: 1
> nsDS5ReplicaBindDN: cn=sync user,cn=config
> nsDS5ReplicaId: 65535
> nsDS5ReplicaRoot: dc=example,dc=com
> nsDS5ReplicaType: 3
> objectClass: top
> objectClass: nsDS5Replica
> objectClass: extensibleobject
> EOF
adding new entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
ldap_add: Operations error (1)
	additional info: Attribute nsDS5ReplicaId value (65535) is invalid, must be a number between 1 and 65534.

But I can modify it like below
[root@qeos-11 upstream]# ldapmodify -h localhost -p 389 -D "cn=Directory manager" -w Secret123 << EOF
> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
> changetype: modify
> replace: nsDS5ReplicaId
> nsDS5ReplicaId: 65535
> EOF
modifying entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"

Is it as expected?

Comment 7 mreynolds 2018-01-29 14:43:58 UTC
There is a still a bug that needs to be fixed

Comment 9 Amita Sharma 2018-02-07 07:23:24 UTC
[root@qeos-34 upstream]# ldapmodify -h localhost -p 39001 -D "cn=Directory manager" -w password << EOF
> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
> changetype: modify
> replace: nsDS5ReplicaId
> nsDS5ReplicaId: 65535
> EOF
modifying entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
ldap_modify: Server is unwilling to perform (53)
	additional info: Attribute nsDS5ReplicaId value (65535) is invalid, must be a number between 1 and 65534.

[root@qeos-34 upstream]# ldapmodify -a -h localhost -p 389 -D "cn=Directory manager" -w Secret123 << EOF
> dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
> cn: replica
> nsDS5Flags: 1
> nsDS5ReplicaBindDN: cn=sync user,cn=config
> nsDS5ReplicaId: 65535
> nsDS5ReplicaRoot: dc=example,dc=com
> nsDS5ReplicaType: 3
> objectClass: top
> objectClass: nsDS5Replica
> objectClass: extensibleobject
> EOF
adding new entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
ldap_add: Operations error (1)
	additional info: Attribute nsDS5ReplicaId value (65535) is invalid, must be a number between 1 and 65534.

This is working fine with new build. Just one query out of curiosity in above two operations we have two different return codes - ldap_modify: Server is unwilling to perform (53) and ldap_add: Operations error (1) , Is it by design?
Thanks.

Comment 10 Amita Sharma 2018-02-19 08:13:12 UTC
Marking this bug as verified as originally reported issue is solve.

Comment 11 mreynolds 2018-02-19 13:18:15 UTC
> 
> This is working fine with new build. Just one query out of curiosity in
> above two operations we have two different return codes - ldap_modify:
> Server is unwilling to perform (53) and ldap_add: Operations error (1) , Is
> it by design?
> Thanks.

It is by design, while the error codes are different from this point of view, they are consistent in the replication code: Add validation uses one error code, while modify validation uses a different error code).  We could make them the same, but that's not in the scope of this bug.

Comment 14 errata-xmlrpc 2018-04-10 14:23:50 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.

https://access.redhat.com/errata/RHBA-2018:0811


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