389-ds-base

Clone
Source Code
GIT

#47950 Bind DN tracking unable to write to internalModifiersName without special permissions
Closed: wontfix None Opened 9 years ago by pj101.

Closed: wontfix
Reopen Issue

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.

I gues i've found out where the problem came from. I've used the attribute uniqueness plugin instance with
{{{
nsslapd-pluginType: preoperation
}}}
instead of
{{{
nsslapd-pluginType: betxnpreoperation
}}}

It was due the automated configuration scripts using the plugin template from 1.2.10.x

After changing the nsslapd-pluginType to betxnpreoperation everything works ok. I'm closing the ticket.

Well, in fact the bug is still here - the previous test when i thought that everything was ok was in fact with the wrong account. The bug exists even if uniqueness plugin is disabled.

Moreover, i am unable to edit replication agreements when 'nsslapd-plugin-binddn-tracking' is 'on' - any modification of port or replication protocol results in "unwilling to perform". Putting 'nsslapd-plugin-binddn-tracking' to 'off' permits to edit the same replica even without restart of ns-slapd.

Don't know if it's the same bug or i should open another ticket for it.

Replying to [comment:4 pj101]:

Moreover, i am unable to edit replication agreements when 'nsslapd-plugin-binddn-tracking' is 'on' - any modification of port or replication protocol results in "unwilling to perform". Putting 'nsslapd-plugin-binddn-tracking' to 'off' permits to edit the same replica even without restart of ns-slapd.

Don't know if it's the same bug or i should open another ticket for it.

I'm not reproducing the replication configuration failures, but I'm using "directory manager" to make those config changes. Are you authenticating as "Directory Manager" when the replication configuration changes fail? Or as some other "admin" user?

Can you please give an example of the replication configuration failure(ldapmodify command and output, etc)? Basically I need a reproducible test case please.

I fixed the original issue(err=50), but I want to make sure I'm addressing this replication issue as well.

Thanks,
Mark

I'm also using directory manager. In our case we renamed it to "cn=X LDAP Root" (nsslapd-rootdn: cn=X LDAP Root).

Here is the ldif file:
{{{
version: 1

dn: cn=Replication from ldap-model.polytechnique.fr to ldap-edev.polytechnique.fr,cn=replica,cn=dc\3Did\2Cdc\3Dpolytechnique\2Cdc\3Dedu,cn=mapping tree,cn=config
changetype: modify
replace: nsDS5ReplicaPort
nsDS5ReplicaPort: 389
-
}}}

With autobind:
{{{
[17/Nov/2014:21:41:58 +0100] conn=167 fd=256 slot=256 connection from local to /Local/dirsrv/var/run/slapd-model.socket
[17/Nov/2014:21:41:58 +0100] conn=167 AUTOBIND dn="cn=X LDAP Root"
[17/Nov/2014:21:41:58 +0100] conn=167 op=0 BIND dn="cn=X LDAP Root" method=sasl version=3 mech=EXTERNAL
[17/Nov/2014:21:41:58 +0100] conn=167 op=0 RESULT err=0 tag=97 nentries=0 etime=0.003000 dn="cn=X LDAP Root"
[17/Nov/2014:21:41:58 +0100] conn=167 op=1 SRCH base="cn=config" scope=2 filter="(nsds5replicaTimeout=*)" attrs=ALL
[17/Nov/2014:21:41:58 +0100] conn=167 op=1 RESULT err=0 tag=101 nentries=1 etime=0.003000
[17/Nov/2014:21:42:20 +0100] conn=167 op=2 MOD dn="cn=Replication from ldap-model.polytechnique.fr to ldap-edev.polytechnique.fr,cn=replica,cn=dc\3Did\2Cdc\3Dpolytechnique\2Cdc\3Dedu,cn=mapping tree,cn=config"
[17/Nov/2014:21:42:20 +0100] conn=167 op=2 RESULT err=53 tag=103 nentries=0 etime=0.002000
[17/Nov/2014:21:43:07 +0100] conn=167 op=-1 fd=256 closed - B1
}}}

With simple bind:

{{{
[root@ldap-model ~]# ldapmodify -D "cn=X LDAP Root" -W -f change-rep.ldif
Enter LDAP Password:
modifying entry "cn=Replication from ldap-model.polytechnique.fr to ldap-edev.polytechnique.fr,cn=replica,cn=dc\3Did\2Cdc\3Dpolytechnique\2Cdc\3Dedu,cn=mapping tree,cn=config"
ldap_modify: Server is unwilling to perform (53)
}}}

{{{

[17/Nov/2014:21:44:32 +0100] conn=168 fd=256 slot=256 connection from 127.0.0.1 to 127.0.0.1
[17/Nov/2014:21:44:32 +0100] conn=168 op=0 BIND dn="cn=X LDAP Root" method=128 version=3
[17/Nov/2014:21:44:32 +0100] conn=168 op=0 RESULT err=0 tag=97 nentries=0 etime=0.002000 dn="cn=x ldap root"
[17/Nov/2014:21:44:32 +0100] conn=168 op=1 MOD dn="cn=Replication from ldap-model.polytechnique.fr to ldap-edev.polytechnique.fr,cn=replica,cn=dc\3Did\2Cdc\3Dpolytechnique\2Cdc\3Dedu,cn=mapping tree,cn=config"
[17/Nov/2014:21:44:32 +0100] conn=168 op=1 RESULT err=53 tag=103 nentries=0 etime=0.002000
[17/Nov/2014:21:44:32 +0100] conn=168 op=2 UNBIND
[17/Nov/2014:21:44:32 +0100] conn=168 op=2 fd=256 closed - U1
}}}

I was able to reproduce it. I also found other areas where internalModifersname would cause issues. I have a fix for all of this, but I need to write up a lib389 testcase before I can send the patch out for review.

6ee9a1b..c973e71 master -> master
commit c973e71
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Nov 18 09:24:21 2014 -0500

ce0cda2..fa8f7dc 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit fa8f7dc

0d6f6ca..9c44c63 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 9c44c63

972396d..cd06271 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit cd0627116c602036eabab8387d0ed65e798a85f9

d9274e2..0c47dfb 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 0c47dfb

What about "internalCreatorsname" - it's not listed in this patch?
This attribute is supposed to be created only during the "add" operation and the "add" ACL does not allow to indicate any particular future entry attributes, so i think i should be ok?

Replying to [comment:12 pj101]:

What about "internalCreatorsname" - it's not listed in this patch?
This attribute is supposed to be created only during the "add" operation and the "add" ACL does not allow to indicate any particular future entry attributes, so i think i should be ok?

Yeah, it's fine. If it wasn't okay we would of have also of seen special code for creatorsname in various places in the code.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1171356

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1171357

Metadata Update from @pj101:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11.33
7 years ago

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

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
None
None
None
major
ack
Community
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.