Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <851984657.1207172131885.JavaMail.jira@brutus>
Date: Wed, 2 Apr 2008 14:35:31 -0700 (PDT)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Updated: (DIRSERVER-955) FilterMatch permissions are not
 being handled in Access Control decisions
In-Reply-To: <10826689.1180818615754.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DIRSERVER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny updated DIRSERVER-955:
----------------------------------------

    Fix Version/s:     (was: 1.5.2)
                   2.0.0

No time to get it done for 1.5.2. I even suggest that we focus on it for 2.0, as the ACI part needs a full review.

> FilterMatch permissions are not being handled in Access Control decisions
> -------------------------------------------------------------------------
>
>                 Key: DIRSERVER-955
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-955
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.5.0
>            Reporter: Ersin Er
>            Assignee: Ersin Er
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> FilterMatch is a Directory operation effective on Attributes and their values and it's subject to Access Control according to the ACI system. In order to be able to use an attribute and it's value in a search filter which is to be executed on an entry, appropriate FilterMatch permissions should be set (with grantFilterMatch probably).
> Current implementation of ApacheDS ACI subsystem just do not handle FilterMatch permissions. So any permissions related to FilterMatch operation (grant/denyFilterMatch) are simply discarded. The more interesting thing is that X.500 spec does not tell anything about this permission in detail; it does not mention it in the Access Control Decision Function (ACFD) algorithm. However, David Chadwick mentions this process as follow in his book, The X.500 Book:
> "... For each entry that has been included in the scope of the Search, the next step is to evaluate the
> filter. This requires permission to use the attributes held in the entry for matching against items in
> the filter (w/w 8.3). Permission is first required to use the attribute type for filtering (grant
> FilterMatch for item attributeType). If permission is not given, then the filter item evaluates to
> undefined. This is exactly the same result as if the attribute were not present in the entry. If
> permission is given, then filter items using attribute types can be evaluated straight away. Filter
> items using attribute values also require FilterMatch permission on each attribute value that is to be
> used in the matching. Values without the grant FilterMatch permission are ignored. Any attribute
> values with FilterMatch permission, are evaluated against the filter item, and will yield True or
> False. If no value permissions are granted, a filter item will evaluate to False. After completing the
> evaluation of the filter, an entry will either be selected for or discarded from inclusion in the Search
> result. ..."
> This need to be further researched but this issue is filed here in order to make a note. If I am correct, this is a serious issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.