389-ds-base

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

Closed: wontfix
Reopen Issue

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

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

0001-Ticket-49408-Server-allows-to-set-any-nsds5replicaid.patch

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

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)

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.

45d2fd4b5..296f0abb7 master -> master

73977eb1c..42a23c09e 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)

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

0001-Issue-49408-Add-a-test-case-for-nsds5ReplicaId-check.patch

Yep, happy with this test,

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

commit 4c4d3c13ab8e7be8e62c2321f93590efecbdb453
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)
Metadata
None
None
None
None
ack
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.