You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Ersin Er (JIRA)" <ji...@apache.org> on 2007/06/02 23:10:15 UTC
[jira] Created: (DIRSERVER-955) FilterMatch permissions are not
being handled in Access Control decisions
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: 1.5.2
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.
[jira] Commented: (DIRSERVER-955) FilterMatch permissions are not
being handled in Access Control decisions
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583702#action_12583702 ]
Alex Karasulu commented on DIRSERVER-955:
-----------------------------------------
Ersin can you give us status or feedback on this issue. Trying to determine if it's something we need to get into 1.5.2. Thanks!
> 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: 1.5.2
>
>
> 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.
[jira] Updated: (DIRSERVER-955) FilterMatch permissions are not
being handled in Access Control decisions
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ 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: 2.0.0-RC1
(was: 2.0.0)
Moved back to 2.0.0-RC1
> 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-RC1
>
>
> 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.
[jira] Updated: (DIRSERVER-955) FilterMatch permissions are not
being handled in Access Control decisions
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ 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.