This bug is not reproducible straightforward. I will give all the possible data to understand in which conditions it is happening.
nsslapd-schemacheck: off nsslapd-syntaxcheck: off
[07/Nov/2014:13:21:53 +0100] NSACLPlugin - __aclp__init_targetattr: targetattr "usersSMIMECertificate" does not exist in schema. Please add attributeTypes "usersSMIMECertificate" to schema if necessary.
The consequence is that list of ACI's are replaced by ACI_ALL:
"(targetattr=\"*\")(version 3.0; acl \"Allow Everyone\"; allow (all) (userdn = \"ldap:///anyone\") ;)";
Additional notes:
[root@rh6 ~]# locale LANG=pt_BR.UTF-8 LC_CTYPE="pt_BR.UTF-8" LC_NUMERIC="pt_BR.UTF-8" LC_TIME="pt_BR.UTF-8" LC_COLLATE="pt_BR.UTF-8" LC_MONETARY="pt_BR.UTF-8" LC_MESSAGES="pt_BR.UTF-8" LC_PAPER="pt_BR.UTF-8" LC_NAME="pt_BR.UTF-8" LC_ADDRESS="pt_BR.UTF-8" LC_TELEPHONE="pt_BR.UTF-8" LC_MEASUREMENT="pt_BR.UTF-8" LC_IDENTIFICATION="pt_BR.UTF-8" LC_ALL=
but I couldn't reproduce it either by setting it.
DSContentPage.actionPerformed(): acl ContentModel.actionACL: ACI and users are on different directories ContentModel.actionACL: users will be search from <suffix> Error reading ACI: 32 Message: null Matched DN: null
(See ACIManager.java)
ACI_ALL + one more aci existent in the group of modified aci's:
time: 20141102211723 dn: <suffix> changetype: modify replace: aci aci: (targetattr="*")(version 3.0; acl "Allow Everyone"; allow (all) (userdn = "ldap:///anyone") ;) aci: (targetattr = "facsimileTelephonenumber || homePhone || jpegphoto || mobi le || telephoneNumber || userPassword") (version 3.0;acl "Self Write para atr ib comuns";allow (write)(userdn = "ldap:///self");)
"Allow Everyone" aci is always present.
If we take a look at ACIEditor,java, this aci is always added to the group, then deleted afterwards. Seems a bug but still it's not reproducible but in customer site.
This is the systematic testcase:
(NOTE: no particular setting in the directory nor specific locale)
stop server
import this ldif file: [root@rh6 ~]# cat repr2.ldif version: 1
dn: o=redhat objectClass: organization objectClass: top o: redhat aci: (targetattr = "facsimileTelephonenumber || invalidattr") (version 3.0 ;acl "invalid aci";allow (write)(userdn = "ldap:///self");) aci: (targetattr = "*") (version 3.0;acl "valid aci";allow (read,compare,search)(userdn = "ldap:///cn=user1,ou=people,o=redhat" or userdn = "ldap:///cn=user0,ou=people,o=redhat");)
Note two aci's (one including an invalid attr).
start server
list aci's under o=redhat:
[root@rh6 ~]# ldapsearch -xLLL -p 2389 -h localhost -D "cn=directory manager" -w secret12 -b "o=redhat" aci dn: o=redhat aci: (targetattr = "facsimileTelephonenumber || invalidattr") (version 3.0 ;ac l "invalid aci";allow (write)(userdn = "ldap:///self");) aci: (targetattr = "*") (version 3.0;acl "valid aci";allow (read,compare,searc h)(userdn = "ldap:///cn=user1,ou=people,o=redhat" or userdn = "ldap:///cn=use r0,ou=people,o=redhat");)
Open ds console.
click on entry "o=redhat". Set access permissions (CTRL-L)
choose "valid aci", "Edit ...", "Edit Manually".
click on "Check Syntax"
This should be just a check but audit log shows:
time: 20141110102920 dn: o=redhat changetype: modify replace: aci aci: (targetattr="")(version 3.0; acl "Allow Everyone"; allow (all) (userdn = "ldap:///anyone") ;) aci: (targetattr = "") (version 3.0;acl "valid aci";allow (read,compare,searc h)(userdn = "ldap:///cn=user1,ou=people,o=redhat" or userdn = "ldap:///cn=use r0,ou=people,o=redhat");) - replace: modifiersname modifiersname: cn=directory manager - replace: modifytimestamp modifytimestamp: 20141110092920Z
[root@rh6 ~]# ldapsearch -xLLL -p 2389 -h localhost -D "cn=directory manager" -w secret12 -b "o=redhat" aci dn: o=redhat aci: (targetattr = "") (version 3.0;acl "valid aci";allow (read,compare,searc h)(userdn = "ldap:///cn=user1,ou=people,o=redhat" or userdn = "ldap:///cn=use r0,ou=people,o=redhat");) aci: (targetattr="")(version 3.0; acl "Allow Everyone"; allow (all) (userdn = "ldap:///anyone") ;)
(invalid aci has been replaced by "Allow Everyone")
As aditional info, this is console log exactly at check syntax:
ACI: (targetattr = "") (version 3.0; acl "valid aci"; allow (read,compare,search) (userdn = "ldap:///cn=user1,ou=people,o=redhat" or userdn = "ldap:///cn=user0,ou=people,o=redhat") ;) ACI Replace Error: 21 ACI: (targetattr = "") (version 3.0; acl "valid aci"; allow (read,compare,search) (userdn = "ldap:///cn=user1,ou=people,o=redhat" or userdn = "ldap:///cn=user0,ou=people,o=redhat")
So the aci syntax check does the following:
[1] Store the existing aci's (all of them) [2] Writes two generic aci's [3] Attempts to add the original aci's to check their syntax [4] The syntax check fails, and all the original aci's are never restored.
We get into this state because we imported an ldif with an invalid aci, and we do not check aci syntax during imports.
Looking into a better way to test aci syntax. Worst case scenario we remove the invalid aci(unless fixed), and the remaining valid aci's remain intact.
Mark, thanks a lot for taking a look so quickly.
In fact, not sure if customer will accept the worst case scenario.
I imagine a situation where schemacheck is off and the custom schema will be added in a later stage during the deployment (repairing the invalid aci's). I think the invalid aci's in this case should be kept.
Replying to [comment:5 gparente]:
No problem :-)
Why can't the customer just fix their aci's?
The core server does now allow you to add invalid aci's, and somehow disabling aci syntax checking could allow very "bad" aci's to be added to the database that could potentially crash the server upon aci porcessing. We would have to do a large rewrite of the acl code to allow broken aci's to be added. This does not make sense. So this is not an option.
Now, we could skip the schema check for target attributes, but once again this could negativity affect other users who have accidental typo's in their aci's - those invalid aci's would go unnoticed, and would essentially break the expected access control policy.
If anything, the real bug here is that you can import invalid aci's.
Now, there is still a bug with the console wiping out all the existing aci's during syntax checking if one of the aci's is invalid, but I still don't believe we should allow invalid aci's to be added.
If they want invalid aci's to be allowed, then that request is an RFE, and needs to go through product management.
Regards, Mark
thanks for clarifying, Mark and Nathan. Your proposed fix is the right one.
I thought customer wanted to repair schema afterwards.
attachment 0001-Ticket-47946-ACI-s-are-replaced-by-ACI_ALL-after-edi.patch
This patch is depend on having the fix for ticket 47953 in place.
To ssh://git.fedorahosted.org/git/idm-console-framework.git d4e10b5..f525cda master -> master
commit f525cda752e27b515eaf845511f90bd15f74b1d2 Author: Mark Reynolds mreynolds@redhat.com Date: Wed Nov 12 14:43:31 2014 -050
Seems to be the same issue as in Bugzilla #1049374 and Redhat case 01000937
Replying to [comment:12 scne59]:
Yes, this fix also addresses that exact issue. I'll update the bug.
Revise ACI syntax checking 0001-Ticket-47946-Need-to-revise-console-aci-syntax-check.patch
To ssh://git.fedorahosted.org/git/idm-console-framework.git 2dd2c9a..c288e15 master -> master
commit c288e1525f59c2faaad9ac141de7248fcf6a54fd Author: Mark Reynolds mreynolds@redhat.com Date: Tue Apr 28 10:37:30 2015 -0400
Original patch had a regression when adding new aci's, reopening...
Fix regression with first patch 0001-Ticket-47946-Fix-regression-with-original-patch.patch
12addf4..8f3302e master -> master commit 8f3302e0ca4e7d2257266350248bf380ecea445e Author: Mark Reynolds mreynolds@redhat.com Date: Tue May 5 16:41:56 2015 -0400
Just tested ok.
Thanks a lot, Mark.
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 389-admin,console 1.1.36
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/1277
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.