#47946 ACI's are replaced by "ACI_ALL" after editing goup of ACI's including invalid one.
Closed: wontfix None Opened 9 years ago by gparente.

This bug is not reproducible straightforward. I will give all the possible data to understand in which conditions it is happening.

  • schema check and syntax off:

nsslapd-schemacheck: off
nsslapd-syntaxcheck: off

  • import ldif containing a set of entries where one of them includes an attribute not present in the schema.

[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.

  • open ds console, directory tab, click on suffix containing these set of aci's (or Ctrl-L)
  • click on a valid aci.
  • "edit..."
  • "edit Manually"
  • "Check syntax" (ok)
  • "ok" (to go back to aci's window).
  • "ok" (to go back to suffix). => Error, LDapException: Invalid Syntax (21)
  • then "cancel".

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:

  • customer is using this locale:

[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.

  • console in debug mode shows these messages which seems to explain issue:

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)

  • An extract of auditlogs shows the full group of aci's are replaced by:

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

entry-id: 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

  • List aci's:

[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]:

Mark, thanks a lot for taking a look so quickly.

No problem :-)

In fact, not sure if customer will accept the worst case scenario.

Why can't the customer just fix their aci's?

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.

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.

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]:

Seems to be the same issue as in Bugzilla #1049374 and Redhat case 01000937

Yes, this fix also addresses that exact issue. I'll update the bug.

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...

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

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

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.