Summary: | Bind DN tracking unable to write to internalModifiersName without special permissions | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Noriko Hosoi <nhosoi> |
Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.0 | CC: | amsharma, mreynolds, nhosoi, nkinder, rmeggins |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.3.3.1-10.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-03-05 09:40:02 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: |
Description
Noriko Hosoi
2014-12-06 00:03:47 UTC
Fixed upstream Please suggest verification steps, executed below which did not work:: ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: cn=config > changetype: modify > replace: nsslapd-plugin-binddn-tracking > nsslapd-plugin-binddn-tracking: on > EOF modifying entry "cn=config" ldapmodify -D "cn=directory manager" -w Secret123 -p 389 -h localhost << EOF > dn: uid=ami,dc=example,dc=com > changetype: modify > replace: aci > aci: (targetattr = "objectClass || uniqueMember || owner || cn || description || businessCategory" ) (version 3.0;acl "bug"; allow (add, delete, read, compare, search, write)(userdn="ldap:///uid=ami1,dc=example,dc=com");) > EOF modifying entry "uid=ami,dc=example,dc=com" ldapadd -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 << EOF dn: uid=ami1,dc=example,dc=com cn: ams sn: ams givenname:ams objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: ami1 mail: ams userpassword: Secret123 EOF adding new entry "uid=ami1,dc=example,dc=com" ldapmodify -D "uid=ami,dc=example,dc=com" -w Secret123 -p 389 -h localhost << EOF dn: uid=ami1,dc=example,dc=com changetype: modify replace: internalModifiersName internalModifiersName: Amita EOF Hi Ami, The steps to verify is found in this patch: https://fedorahosted.org/389/attachment/ticket/47950/0001-Ticket-47950-Bind-DN-tracking-unable-to-write-to-int.patch Please see this python script written by Mark. dirsrvtests/tickets/ticket47950_test.py The issue is an ordinary user who is given the right to behave as a special user (e.g., directory manager) used to fail because the permission to write the user to internalModifiersName was missing. Now the issue was fixed. So, the goal to verify this bug is not updating internalModifiersName directly, but the special user "uid=ami1,dc=example,dc=com" can do something higher level such as creating a replication agreement and modifying it without any problems. Thanks, --noriko There are two problems here: one is when you enable plugin bind dn tracking, and you perform an operation as a normal user(not Directory Manager!), that operation will unexpectedly fail because the access control plugin is incorrectly checking the rights for the "internalModifiersname" update. Access control should be ignoring internal updates for this attribute. The other issue is around the Directory Manager not being able to update replication settings when plugin bind dn tracking is enabled: Verification steps: [1] Enable plugin bind dn tracking: "nsslapd-plugin-binddn-tracking: on" [2] Add two users: userA & userB [3] Add an aci that allows userA "all" rights to "dc=example,dc=com" [4] Bind as userA, and modify the "sn" attribute of userB --> if this succeeds we have successsfully tested the first part [5] Setup replication(enable replication and create a replication agreement). The repl agreement does not need to point to a valid server - we just need the config entry created so we can test that we can modify it: [6] As "Directory Manager" modify the replication config ldapmodify -D "cn=directory manger" .... dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype; modify replace: nsDS5ReplicaId nsDS5ReplicaId: 8888 [7] Modify the repl agreement ldapmodify -D "cn=directory manger" .... dn: cn=testPluginTracking,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: nsDS5ReplicaPort nsDS5ReplicaPort: 9999 [8] If we get here we have successfully tested the second part. [root@dhcp201-126 ~]# ps -aef | grep slapd svrbld 7181 1 0 17:34 ? 00:00:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-dhcp201-126 -i /var/run/dirsrv/slapd-dhcp201-126.pid -w /var/run/dirsrv/slapd-dhcp201-126.startpid svrbld 10356 1 0 17:37 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M1 -i /var/run/dirsrv/slapd-M1.pid -w /var/run/dirsrv/slapd-M1.startpid svrbld 10793 1 0 17:37 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M2 -i /var/run/dirsrv/slapd-M2.pid -w /var/run/dirsrv/slapd-M2.startpid svrbld 11254 1 0 17:38 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M3 -i /var/run/dirsrv/slapd-M3.pid -w /var/run/dirsrv/slapd-M3.startpid svrbld 11739 1 0 17:38 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-M4 -i /var/run/dirsrv/slapd-M4.pid -w /var/run/dirsrv/slapd-M4.startpid root 13128 3645 0 17:53 pts/0 00:00:00 grep --color=auto slapd [root@dhcp201-126 ~]# netstat -nlp | grep slapd tcp6 0 0 :::30104 :::* LISTEN 11254/ns-slapd tcp6 0 0 :::30105 :::* LISTEN 11254/ns-slapd tcp6 0 0 :::30106 :::* LISTEN 11739/ns-slapd tcp6 0 0 :::32730 :::* LISTEN 7181/ns-slapd tcp6 0 0 :::30107 :::* LISTEN 11739/ns-slapd tcp6 0 0 :::30100 :::* LISTEN 10356/ns-slapd tcp6 0 0 :::30101 :::* LISTEN 10356/ns-slapd tcp6 0 0 :::30102 :::* LISTEN 10793/ns-slapd tcp6 0 0 :::30103 :::* LISTEN 10793/ns-slapd PART 1 ======= [root@dhcp201-126 ~]# ldapmodify -D "cn=directory manager" -w Secret123 -p 30100 -h localhost << EOF > dn: cn=config > changetype: modify > replace: nsslapd-plugin-binddn-tracking > nsslapd-plugin-binddn-tracking: on > EOF modifying entry "cn=config" [root@dhcp201-126 ~]# ldapadd -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 << EOF > dn: uid=ami,dc=example,dc=com > cn: ams > sn: ams > givenname: ams > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > uid: ami > mail: ams > userpassword: Secret123 > EOF adding new entry "uid=ami,dc=example,dc=com" [root@dhcp201-126 ~]# ldapadd -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 << EOF > dn: uid=B,dc=example,dc=com > cn: B > sn: B > givenname: B > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > uid: B > mail: B > userpassword: Secret123 > EOF adding new entry "uid=B,dc=example,dc=com" [root@dhcp201-126 ~]# ldapmodify -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 << EOF > dn: dc=example,dc=com > changetype: modify > replace: aci > aci: (targetattr="*")(version 3.0; acl "Managerami"; allow (all) (userdn="ldap:///uid=ami,dc=example,dc=com");) > EOF modifying entry "dc=example,dc=com" [root@dhcp201-126 ~]# ldapmodify -h localhost -p 30100 -D "uid=ami,dc=example,dc=com" -w Secret123 << EOF > dn: uid=B,dc=example,dc=com > changetype: modify > replace: sn > sn: new > EOF modifying entry "uid=B,dc=example,dc=com" [root@dhcp201-126 ~]# ldapsearch -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 -b "uid=B,dc=example,dc=com" # extended LDIF # # LDAPv3 # base <uid=B,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # B, example.com dn: uid=B,dc=example,dc=com sn: new cn: B givenName: B objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: B mail: B userPassword:: e1NTSEF9Y2lWTUp6RzhKVWVyT1ZvTkN5TTIrOCtTaWhKUmRKMVB3NFNyZHc9PQ= = # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ========================= Part 2 ------ [root@dhcp201-126 ~]# ldapmodify -h localhost -p 30100 -D "cn=directory manager" -w Secret123 << EOF > dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > changetype: modify > replace: nsDS5ReplicaType > nsDS5ReplicaType: 2 > EOF modifying entry "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" [root@dhcp201-126 ~]# ldapmodify -h localhost -p 30100 -D "cn=directory manager" -w Secret123 << EOF > dn: cn=M1_to_M2,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > changetype: modify > replace: nsDS5ReplicaPort > nsDS5ReplicaPort: 9999 > EOF modifying entry "cn=M1_to_M2,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" Both parts are verified successfully. Hence VERIFIED. 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 |