From cf8219f79849c4f4539681ff294134f0de7e1a8b Mon Sep 17 00:00:00 2001 From: Mark Reynolds Date: Wed, 25 Apr 2018 20:30:59 -0400 Subject: [PATCH] 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: ? --- ldap/servers/plugins/acl/acl.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/ldap/servers/plugins/acl/acl.c b/ldap/servers/plugins/acl/acl.c index bc154c78f..6d105f4fa 100644 --- a/ldap/servers/plugins/acl/acl.c +++ b/ldap/servers/plugins/acl/acl.c @@ -1088,9 +1088,23 @@ acl_read_access_allowed_on_entry( ** 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) + 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. @@ -2908,6 +2922,12 @@ acl__TestRights(Acl_PBlock *aclpb, int access, const char **right, const char ** 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, ""); -- 2.13.6