RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1044152 - ChainOnUpdate: "cn=directory manager" can modify userRoot on consumer without changes being chained or replicated. Directory integrity compromised.
Summary: ChainOnUpdate: "cn=directory manager" can modify userRoot on consumer without...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-17 21:29 UTC by Nathan Kinder
Modified: 2020-09-13 20:07 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 09:31:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 314 0 None closed ChainOnUpdate: "cn=directory manager" can modify userRoot on consumer without changes being chained or replicated. Direc... 2020-12-01 11:06:11 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Nathan Kinder 2013-12-17 21:29:50 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/314

Setup would be as follows
be1.foo.com is Master - (dc=foo,dc=com)
be2.foo.com is Consumer to be1, configured to chain on  update - (dc=foo,dc=com)

compromised 
It should be viewed as problematic that the database on a consumer could be directly modified by "cn=directory manager" and those changes are not reflected on the Master (or other masters, hubs, or consumers, for that matter) 

Hypothetically speaking... 
"cn=directory manager" could bind to be1.foo.com and modify the following dn..
dn: uid=jim,dc=foo,dc=com 
changetype: modify 
replace: sn
sn: changed on be1

I could then search be1.foo.com (Master) and be2.foo.com (consumer)
and find the value for "sn" on "uid=jim,dc=foo,dc=com" is "changed on be1" on both servers

The above makes sense.

Now, If i were to  make the same change to be2...
"cn=directory manager" binds to be2.foo.com and modifies ..
changetype: modify 
replace: sn
sn: changed on be2

I would then search be1.foo.com (Master) and find sn to have a value of "changed on be1"
a search of be2.foo.com (Consumer) would show sn has a value of "changed on be2"

It seems this could have a detrimental effect on the integrity of the environment.

Possible Options:
A) ensure "cn=directory manager"s actions on a consumer/ "chain on update" are replicated (chain directory manager's changes to userRoot);
B) prevent ^ from making changes to userRoot/(dc=foo,dc=com) that will not be replicated/chained;
C) give ^ a referral to a master if changes are destined for userRoot/(dc=foo,dc=com);
D) ?
Comment 3 Ludwig 2014-11-18 12:54:58 UTC 
the 2 testscenarios and expected behaviour are described in the corresponding ticket in comment #15
Comment 4 Sankar Ramalingam 2014-11-25 09:57:53 UTC 
(In reply to Ludwig from comment #3)
> the 2 testscenarios and expected behaviour are described in the
> corresponding ticket in comment #15

The correct link - https://fedorahosted.org/389/ticket/314#comment:15
Comment 5 Viktor Ashirov 2014-11-29 00:08:21 UTC 
$ rpm -qa | grep 389
389-ds-base-1.3.3.1-9.el7.x86_64
389-ds-base-debuginfo-1.3.3.1-9.el7.x86_64
389-ds-base-libs-1.3.3.1-9.el7.x86_64

[0] Setup: Master-Consumer replication - M1 (1189) and C1 (1389)

[1] Configure chain on update:
1. Add aci to M1:

$ ldapmodify -v -h localhost:1189 -D "cn=Directory Manager" -w "Secret123" << EOF
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database l
 inks";allow (proxy) (userdn = "ldap:///cn=SyncManager,cn=config");)
-
EOF


2. Add new database link DBLink1 to C1 for suffix dc=example,dc=com : 

$ ldapmodify -v -h localhost:1389 -D "cn=Directory Manager" -w "Secret123" << EOF
dn: cn=DBLink1,cn=chaining database,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsBackendInstance
cn: DBLink1
nsslapd-suffix: dc=example,dc=com
nsslapd-parent-suffix: dc=example,dc=com 
nsmultiplexorbinddn: cn=SyncManager,cn=config
nsfarmserverurl: ldap://localhost:1189/
nsmultiplexorcredentials: Secret123
EOF

3. Add second backend and distribution plugin to suffix on C1: 
$ ldapmodify -v -h localhost:1389 -D "cn=Directory Manager" -w "Secret123" << EOF
dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
add: nsslapd-backend
nsslapd-backend: DBLink1
-
add: nsslapd-distribution-funct
nsslapd-distribution-funct: repl_chain_on_update
-
add: nsslapd-distribution-plugin
nsslapd-distribution-plugin: libreplication-plugin
-
replace: nsslapd-state
nsslapd-state: backend
-
EOF

4. Restart servers
$ sudo systemctl restart dirsrv.target

[2] Configure nsslapd-distribution-root-update:

$ ldapmodify -v -h localhost:1389 -D "cn=Directory Manager" -w "Secret123" << EOF
dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsslapd-distribution-root-update
nsslapd-distribution-root-update: referral
-
EOF

and restart C1

[2.1] nsslapd-distribution-root-update: referral

$ ldapmodify -v -h localhost:1389 -D "cn=Directory Manager" -w "Secret123"  << EOF
dn: ou=People,dc=example,dc=com
changetype: modify
replace: description
description: root update
EOF

ldap_initialize( ldap://localhost:1389 )
replace description:
	root update
modifying entry "ou=People,dc=example,dc=com"
ldap_modify: Referral (10)
	matched DN: dc=example,dc=com
	referrals:
		ldap://rhel7ds.brq.redhat.com:1189

Entry doesn't get updated neither on M1 nor on C1 since chaining doesn't work as root -> PASS

[2.2] nsslapd-distribution-root-update: reject

$ ldapmodify -v -h localhost:1389 -D "cn=Directory Manager" -w "Secret123"  << EOF
dn: ou=People,dc=example,dc=com
changetype: modify
replace: description
description: root update
EOF

ldap_initialize( ldap://localhost:1389 )
replace description:
	root update
modifying entry "ou=People,dc=example,dc=com"
ldap_modify: Server is unwilling to perform (53)

Entry doesn't get updated neither on M1 nor on C1 since server rejects such modifications. This is a default option, when nsslapd-distribution-root-update is not explicitly set in cn=config -> PASS


[2.3] nsslapd-distribution-root-update: local

$ ldapmodify -v -h localhost:1389 -D "cn=Directory Manager" -w "Secret123"  << EOF
dn: ou=People,dc=example,dc=com
changetype: modify
replace: description
description: root update
EOF

ldap_initialize( ldap://localhost:1389 )
replace description:
	root update
modifying entry "ou=People,dc=example,dc=com"
modify complete

On M1:
$ ldapsearch -v -h localhost:1189 -x -LLL -o ldif-wrap=no -b dc=example,dc=com '(ou=People)' description
ldap_initialize( ldap://localhost:1189 )
filter: (ou=People)
requesting: description 
dn: ou=People,dc=example,dc=com

On C1: 
$ ldapsearch -v -h localhost:1389 -x -LLL -o ldif-wrap=no -b dc=example,dc=com '(ou=People)' description
ldap_initialize( ldap://localhost:1389 )
filter: (ou=People)
requesting: description 
dn: ou=People,dc=example,dc=com
description: root update

Entry was updated on C1 -> PASS


One minor issue is that nsslapd-distribution-root-update is multivalued attribute and it can be set to contradicting values. 
Other than that everything works as expected, thus marking as VERIFIED.
Comment 7 errata-xmlrpc 2015-03-05 09:31:40 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://rhn.redhat.com/errata/RHSA-2015-0416.html
Note You need to log in before you can comment on or make changes to this bug.