Bug 1171356

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-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: 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
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47950


I've activated bind dn tracking (nsslapd-plugin-binddn-tracking: on). There is an account that has the write to add the entries and to change some attributes (e.g. description). The corresponding ACI:
{{{
dn: ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu
aci: (targetattr = "objectClass || uniqueMember || owner || cn || description || businessCategory" ) (version 3.0;acl "Droits de rejouter/supprimer/modifier les groupes et leurs att
ributs";allow (add, delete, read,compare,search,write)(userdn="ldap:///uid=sync-cours,ou=Comptes generiques,ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu");)
}}}

Any attempt to modify an authorized attribute from the list above (for ex., description) results in

{{{
ldap_modify: Insufficient access (50)
        additional info: Insufficient 'write' privilege to the 'internalModifiersName' attribute of entry 'cn=mec431-2014,ou=2014,ou=cours,ou=enseignement,ou=groupes,dc=id,dc=polytechnique,dc=edu'.

}}}
{{{
[11/Nov/2014:10:38:49 +0100] conn=4 fd=256 slot=256 connection from 129.104.31.54 to 129.104.69.49
[11/Nov/2014:10:38:49 +0100] conn=4 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[11/Nov/2014:10:38:49 +0100] conn=4 op=0 RESULT err=14 tag=97 nentries=0 etime=0.008000, SASL bind in progress
[11/Nov/2014:10:38:49 +0100] conn=4 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[11/Nov/2014:10:38:49 +0100] conn=4 op=1 RESULT err=14 tag=97 nentries=0 etime=0.002000, SASL bind in progress
[11/Nov/2014:10:38:49 +0100] conn=4 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[11/Nov/2014:10:38:49 +0100] conn=4 op=2 RESULT err=0 tag=97 nentries=0 etime=0.001000 dn="uid=sync-cours,ou=comptes generiques,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu"
[11/Nov/2014:10:38:49 +0100] conn=4 op=3 SRCH base="dc=id,dc=polytechnique,dc=edu" scope=2 filter="(cn=MEC431-2014)" attrs=ALL
[11/Nov/2014:10:38:49 +0100] conn=4 op=3 RESULT err=0 tag=101 nentries=1 etime=0.003000
[11/Nov/2014:10:39:00 +0100] conn=4 op=4 MOD dn="cn=MEC431-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu"
[11/Nov/2014:10:39:00 +0100] conn=4 op=4 RESULT err=50 tag=103 nentries=0 etime=0.002000
}}}

The workaround is to add to all the ACIs that allow modifications the right to modify internalModifiersName attribute (if i add it, everything is fine and the attribute internalModifiersName becomes "cn=ldbm database,cn=plugins,cn=config").

Expected behavior : internalModifiersName should be written like modifiersname without  any explicit permission.

Comment 1 mreynolds 2014-12-08 19:10:00 UTC
Fixed upstream

Comment 3 Amita Sharma 2014-12-26 12:24:25 UTC
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

Comment 4 Noriko Hosoi 2015-01-01 02:51:19 UTC
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

Comment 5 mreynolds 2015-01-02 15:23:19 UTC
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.

Comment 6 Amita Sharma 2015-01-28 12:41:06 UTC
[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.

Comment 8 errata-xmlrpc 2015-03-05 09:40:02 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