#49408 Server allows to set any nsds5replicaid in the existing replica entry
Closed: wontfix 6 years ago Opened 6 years ago by mreynolds.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1438526

Description of problem:
We can break the nsds5replicaid attribute rules (it should be 1 to 65534 for
suppliers) if we'll try to modify the existing replication entry.

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

How reproducible:
Always

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

adding new entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config"

[3] Check the entry:
[root@qeos-175 ds]# ldapsearch -h localhost -p 389 -D "cn=Directory manager" -w
Secret123 -b "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
# replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=sync user,cn=config
nsDS5ReplicaId: 7
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaType: 3
objectClass: top
objectClass: nsDS5Replica
objectClass: extensibleobject
nsState:: BwAAAAAAAADycuJYAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
nsDS5ReplicaName: 65766987-188711e7-80a2fa60-3a60cc96
nsds5ReplicaChangeCount: 0
nsds5replicareapactive: 0

[4] Set nsDS5ReplicaId to some wrong_id format:
[root@qeos-175 ds]# ldapmodify -h localhost -p 389 -D "cn=Directory manager" -w
Secret123
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsDS5ReplicaId
nsDS5ReplicaId: wrong_id

modifying entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config"

[5] Check the entry:
[root@qeos-175 ds]# ldapsearch -h localhost -p 389 -D "cn=Directory manager" -w
Secret123 -b "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
# replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=sync user,cn=config
nsDS5ReplicaId: wrong_id
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaType: 3
objectClass: top
objectClass: nsDS5Replica
objectClass: extensibleobject
nsState:: BwAAAAAAAADycuJYAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
nsDS5ReplicaName: 65766987-188711e7-80a2fa60-3a60cc96
nsds5ReplicaChangeCount: 0
nsds5replicareapactive: 0


Actual results:
It is possible to set bogus replica id to the existing replica entry

Expected results:
Operation error should happen when we try to set bogus replica id

Additional info:
- Operation error happens with a wrong replica id when we are creating the
replica entry initially.
- It is impossible to set nsDS5ReplicaId to something in the second time:
[root@qeos-175 ds]# ldapmodify -h localhost -p 389 -D "cn=Directory manager" -w
Secret123
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsDS5ReplicaId
nsDS5ReplicaId: 8

modifying entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config"
ldap_modify: Operations error (1)
        additional info: replica type is already 2 - not changing

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

6 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

6 years ago

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to review
- Custom field type adjusted to None
- Custom field version adjusted to None

6 years ago

The patch is good to me.
I would rather implement it like it is done in type_replicaPurgeDelay (check it is a integer value) and call replica_config_change_type_and_id with new_repl_id being an int.
Then let replica_config_change_type_and_id check if the value is valid.
It is just a minor comment and I am okay with your current patch. ACK

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

6 years ago

The patch is good to me.
I would rather implement it like it is done in type_replicaPurgeDelay (check it is a integer value) and call replica_config_change_type_and_id with new_repl_id being an int.
Then let replica_config_change_type_and_id check if the value is valid.
It is just a minor comment and I am okay with your current patch. ACK

Actually replica_config_change_type_and_id() only checks the replica ID if you are changing the replica type. So if you only change the replica ID this check is not performed. That function is only meant for replica promotion/demotion.

The stroll method also catches all failure cases thanks to "errno" (unlike atoi). That also implies that we should also adjust replica_config_change_type_and_id() to use strtoll as well, but lets do that via a different ticket.

45d2fd4..296f0ab master -> master

73977eb..42a23c0 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

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

6 years ago

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

6 years ago

Yep, happy with this test,

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

6 years ago

commit 4c4d3c1
Author: Simon Pichugin spichugi@redhat.com
Date: Tue Nov 7 19:34:02 2017 +0100

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/2467

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Login to comment on this ticket.

Metadata