This is an automated email from the git hooks/post-receive script.
mreynolds pushed a commit to branch 389-ds-base-1.2.11
in repository 389-ds-base.
commit f4a76bb41d1875e70ad597b4b1c411393f7f286f
Author: Mark Reynolds <mreynolds(a)redhat.com>
Date: Fri Apr 27 09:04:29 2018 -0400
Ticket 49652 - DENY aci's are not handled properly
Bug Description: There are really two issues here. One, when a resource
is denied by a DENY aci the cached results for that resource
are not proprely set, and on the same connection if the same
operation repeated it will be allowed instead of denied because
the cache result was not proprely updated.
Two, if there are no ALLOW aci's on a resource, then we
don't
check the deny rules, and resources that are restricted are
returned to the client.
Fix Description: For issue one, when an entry is denied access reset all the
attributes' cache results to DENIED as it's possible
previously
evaluated aci's granted access to some of these attributes
which
are still present in the acl result cache.
For issue two, if there are no ALLOW aci's on a resource but
there are DENY aci's, then set the aclpb state flags to
process DENY aci's
https://pagure.io/389-ds-base/issue/49652
Reviewed by: tbordaz & lkrispenz(Thanks!!)
(cherry picked from commit 31ba1e793e3c61e2d9b29851a08e39a4fcaf4296)
---
ldap/servers/plugins/acl/acl.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/ldap/servers/plugins/acl/acl.c b/ldap/servers/plugins/acl/acl.c
index 3b0a7ce..53ed6ac 100644
--- a/ldap/servers/plugins/acl/acl.c
+++ b/ldap/servers/plugins/acl/acl.c
@@ -1027,17 +1027,30 @@ acl_read_access_allowed_on_entry (
*/
if ( aclpb->aclpb_state & ACLPB_FOUND_A_ENTRY_TEST_RULE){
/* Do I have access on the entry itself */
- if (acl_access_allowed (pb, e, NULL,
- NULL, access) != LDAP_SUCCESS) {
+ if (acl_access_allowed (pb, e, NULL, NULL, access) != LDAP_SUCCESS) {
/* How was I denied ?
** I could be denied on a DENY rule or because
** there is no allow rule. If it's a DENY from
** a DENY rule, then we don't have access to
** the entry ( nice trick to get in )
*/
- if ( aclpb->aclpb_state &
- ACLPB_EXECUTING_DENY_HANDLES)
- return LDAP_INSUFFICIENT_ACCESS;
+ if (aclpb->aclpb_state & ACLPB_EXECUTING_DENY_HANDLES) {
+ aclEvalContext *c_ContextEval =
&aclpb->aclpb_curr_entryEval_context;
+ AclAttrEval *c_attrEval = NULL;
+ /*
+ * The entire entry is blocked, but previously evaluated allow
aci's might
+ * show some of the attributes as readable in the acl cache, so
reset all
+ * the cached attributes' status to FAIL.
+ */
+ for (size_t j = 0; j < c_ContextEval->acle_numof_attrs;
j++) {
+ c_attrEval = &c_ContextEval->acle_attrEval[j];
+ c_attrEval->attrEval_r_status &=
~ACL_ATTREVAL_SUCCESS;
+ c_attrEval->attrEval_r_status |= ACL_ATTREVAL_FAIL;
+ c_attrEval->attrEval_s_status &=
~ACL_ATTREVAL_SUCCESS;
+ c_attrEval->attrEval_s_status |= ACL_ATTREVAL_FAIL;
+ }
+ return LDAP_INSUFFICIENT_ACCESS;
+ }
/* The other case is I don't have an
** explicit allow rule -- which is fine.
@@ -2754,6 +2767,11 @@ acl__TestRights(Acl_PBlock *aclpb,int access, char **right, char **
map_generic,
result_reason->deciding_aci = NULL;
result_reason->reason = ACL_REASON_NO_MATCHED_RESOURCE_ALLOWS;
+ /* If we have deny handles we should process them */
+ if (aclpb->aclpb_num_deny_handles > 0) {
+ aclpb->aclpb_state &= ~ACLPB_EXECUTING_ALLOW_HANDLES;
+ aclpb->aclpb_state |= ACLPB_EXECUTING_DENY_HANDLES;
+ }
TNF_PROBE_1_DEBUG(acl__TestRights_end,"ACL","",
tnf_string,no_allows,"");
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.