You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-commits@jackrabbit.apache.org by an...@apache.org on 2014/05/16 14:50:12 UTC
svn commit: r1595182 - in
/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security: permission.md
permission/differences.md permission/evaluation.md
Author: angela
Date: Fri May 16 12:50:12 2014
New Revision: 1595182
URL: http://svn.apache.org/r1595182
Log:
OAK-301 : oak docu
Modified:
jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md
jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/differences.md
jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md?rev=1595182&r1=1595181&r2=1595182&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md Fri May 16 12:50:12 2014
@@ -20,22 +20,100 @@ Permissions
### JCR API
-_todo_
+While access control management is a optional feature, a JCR implementation is
+required to support the basic permission checking. The basic requirements for
+the permission evalution are defines as follows
-**`Session#hasPermission` and `Session#checkPermission`**
+> Permissions encompass the restrictions imposed by any access control restrictions
+> that may be in effect upon the content of a repository, either implementation
+> specific or JCR-defined (Access Control Management)., which consists of
-_todo_
+The methods defined to check permissions:
-**JCR Actions**
+- `Session#hasPermission(String absPath, String actions)`
+- `Session#checkPermission(String absPath, String actions)`
-_todo_
+The actions are expected to be a comma separated list of any of the following string constants:
- `Session.ACTION_READ`
- `Session.ACTION_ADD_NODE`
- `Session.ACTION_REMOVE`
- `Session.ACTION_SET_PROPERTY`
-##### Mapping of JCR Actions to Oak Permissions
+**Note**: As of Oak 1.0 the these methods also handle the names of the permissions
+defined by Oak (see `Permissions#getString(long permissions)`).
+
+##### Examples
+###### Test if session has permission to add a new node
+
+Important: `absPath` refers to the node to be created
+
+ Node content = session.getNode("/content");
+ if (session.hasPermission("/content/newNode", Session.ACTION_ADD_NODE)) {
+ content.addNode("newNode");
+ session.save();
+ }
+
+###### Test if session has permission to perform version operations
+
+ Node content = session.getNode("/content");
+ if (session.hasPermission("/content", Permissions.getString(Permissions.VERSION_MANAGEMENT))) {
+ content.checkin();
+ session.save();
+ }
+
+### Oak Permissions
+
+#### Built-in Permissions
+
+Oak 1.0 defines the following [Permissions]:
+
+##### Simple Permissions
+
+Read operations:
+
+- `READ_NODE`
+- `READ_PROPERTY`
+- `READ_ACCESS_CONTROL`
+
+Write operations:
+
+- `ADD_NODE`
+- `REMOVE_NODE`
+- `MODIFY_CHILD_NODE_COLLECTION`
+- `ADD_PROPERTY`
+- `MODIFY_PROPERTY`
+- `REMOVE_PROPERTY`
+- `NODE_TYPE_MANAGEMENT`
+- `MODIFY_ACCESS_CONTROL`
+- `LOCK_MANAGEMENT`
+- `VERSION_MANAGEMENT`
+
+Since Oak 1.0:
+
+- `USER_MANAGEMENT`: : execute user management related tasks such as e.g. creating or removing user/group, changing user password and editing group membership.
+- `INDEX_DEFINITION_MANAGEMENT`: create, modify and remove the oak:index node and it's subtree which is expected to contain the index definitions.
+
+Repository operations:
+
+- `NODE_TYPE_DEFINITION_MANAGEMENT`
+- `NAMESPACE_MANAGEMENT`
+- `PRIVILEGE_MANAGEMENT`
+- `WORKSPACE_MANAGEMENT`
+
+Not used in Oak 1.0:
+
+- `LIFECYCLE_MANAGEMENT`
+- `RETENTION_MANAGEMENT`
+
+##### Aggregated Permissions
+
+- `READ`: aggregates `READ_NODE` and `READ_PROPERTY`
+- `REMOVE`: aggregates `REMOVE_NODE` and `REMOVE_PROPERTY`
+- `SET_PROPERTY`: aggregates `ADD_PROPERTY`, `MODIFY_PROPERTY` and `REMOVE_PROPERTY`
+- `ALL`: aggregates all permissions
+
+#### Mapping of JCR Actions to Oak Permissions
`ACTION_READ`:
@@ -62,56 +140,121 @@ _todo_
- regular properties: `Permissions.MODIFY_PROPERTY`
- non-existing properties: `Permissions.ADD_PROPERTY`
-**Note**
-Since Oak the permission related API calls not only allow to pass the action strings
-defined by JCR specification (see constants defined in `Session.java`) but also
-handles the names of the permission defined by Oak (see `Permissions#getString(long permissions)`).
-
-
-### Oak API
+### Characteristics of the Permission Evaluation
-_todo_
+#### General Notes
-#### Built-in Permissions
+In general the permission evaluation related code in Oak is intended to be
+more clearly separated from the access control management such as defined by the
+JCR and Jackrabbit API. While permission evaluation is considered to be an
+internal feature of the Oak core module, the package
+`org.apache.jackrabbit.oak.spi.security.authorization.permission` provides some
+extensions points that allow to plug custom extensions or implementations of
+the permission evaluation.
-The set of permissions supported by Oak are listed in [Permissions]. The following changes have been compared compared to Jackrabbit 2.x:
+#### Differences wrt Jackrabbit 2.x
-- `READ_NODE`: permission to read a node
-- `READ_PROPERTY`: permission to read a property
-- `ADD_PROPERTY`: permission to create a new property
-- `MODIFY_PROPERTY`: permission to change an existing property
-- `REMOVE`: aggregation of `REMOVE_NODE` and `REMOVE_PROPERTY`
-- `USER_MANAGEMENT`: permission to execute user management related tasks such as e.g. creating or removing user/group, changing user password and editing group membership.
-- `INDEX_DEFINITION_MANAGEMENT`: permission to create, modify and remove the oak:index node and it's subtree which is expected to contain the index definitions.
+see the corresponding [documentation](permission/differences.html).
-The following permissions are now an aggregation of new permissions:
+#### Permissions for Different Operations
-- `READ`: aggregates `READ_NODE` and `READ_PROPERTY`
-- `SET_PROPERTY`: aggregates `ADD_PROPERTY`, `MODIFY_PROPERTY` and `REMOVE_PROPERTY`
+##### Reading
+Due to the fine grained read permissions Oak read access can be separately granted/denied
+for nodes and properties. Granting the `jcr:read` privilege will result in a backwards compatible
+read access for nodes and their properties, while specifying `rep:readNodes` or
+`rep:readProperties` privileges allows to grant or deny access to
+nodes and properties (see also [Privilege Management](../privilege.html) for changes
+in the privilege definitions).
+Together with the restrictions this new behavior now allows to individually grant/deny
+access to properties that match a given name/path/nodetype (and as a possible extension even property value).
+
+Note that accessibility of version content located underneath `/jcr:system/jcr:versionStore`
+is defined by the permissions present with the versionable node. In case the version
+information does no longer have a versionable node in this workspace it's original
+versionable path is used to evaluate the effective permissions that would apply
+to that item if the version was restored. This change is covered by [OAK-444] and
+addresses concerns summarized in [JCR-2963].
+
+##### Property Modification
+Since Oak the former `SET_PROPERTY` permission has been split such to allow for
+more fined grained control on writing JCR properties. In particular Oak clearly
+distinguishes between creating a new property that didn't exist before, modifying
+or removing an existing property.
+
+This will allow to cover those cases where a given `Subject` is only allowed
+to create content without having the ability to modify/delete it later on.
+
+##### Node Removal
+As of Oak `Node#remove()` only requires sufficient permissions to remove the
+target node. See below for configuration parameters to obtain backwards compatible behavior.
+
+##### Rename
+Due to the nature of the diff mechanism in Oak it is no longer possible to distinguish
+between `JackrabbitNode#rename` and a move with subsequent reordering.
+
+##### Move
+The current permission evaluation attempts to provide a best-effort handling to
+achieve a similar behavior that it was present in Jackrabbit 2.x by keeping track
+of transient move operations.
+
+The current implementation has the following limitations with respect to multiple
+move operations within a given set of transient operations:
+
+- Move operations that replace an node that has been moved away will not be
+detected as modification by the diff mechanism and regular permission checks for
+on the subtree will be performed.
+- Moving an ancestor of a node that has been moved will only detect the second
+move and will enforce regular permissions checks on the child that has been moved
+in a first step.
+
+##### Writing Protected Items
+
+Writing protected items requires specific permissions and are not covered by
+regular JCR write permissions. This affects:
+
+- Set/Modify Primary or Mixin Type: `NODE_TYPE_MANAGEMENT`
+- Access Control Content: `MODIFY_ACCESS_CONTROL`
+- Locking: `LOCK_MANAGEMENT`
+- Versioning: `VERSION_MANAGEMENT`
+- User Management: `USER_MANAGEMENT`
+
+##### User Management
+By default user management operations require the specific user management related
+permission to be granted for the editing subject. This permission (including a corresponding privilege)
+has been introduced with Oak 1.0. See below for configuration parameters to obtain backwards compatible behavior.
+
+Executing version related operations and thus writing to the version storre
+requires VERSION_MANAGEMENT permission instead of the regular JCR write permissions
+
+##### Query Index Definitions
+Writing query index definitions requires the specific index definition management
+which is enforce on nodes named "oak:index" and the subtree defined by them.
+Note that the corresponding items are not protected in the JCR sense. Consequently
+any other modification in these subtrees like e.g. changing the primary type
+or adding mixin types is governed by the corresponding privileges.
-#### New Permissions
+#### Details on Permission Evaluation
_todo_
-- `USER_MANAGEMENT`: permission to execute user management related tasks such as e.g. creating or removing user/group, changing user password and editing group membership.
-- `INDEX_DEFINITION_MANAGEMENT`: permission to create, modify and remove the oak:index node and it's subtree which is expected to contain the index definitions.
+##### Administrative Access
+In the default implementation following principals always have full access to
+the whole content repository (except for hidden items that are not exposed
+on the Oak API) irrespective of the access control content:
+- `SystemPrincipal`
+- All instances of `AdminPrincipal`
+- All principals whose name matches the configured administrative principal names (see Configuration section below). This configuration only applies to the permission evaluation and is currently not reflected in other security models nor methods that deal with the administrator (i.e. `User#isAdmin`).
-### Characteristics of the Permission Evaluation
-#### General Notes
+##### Readable Trees
-In general the permission evaluation related code in Oak is intended to be
-more clearly separated from the access control management such as defined by the
-JCR and Jackrabbit API. While permission evaluation is considered to be an
-internal feature of the Oak core module, the package
-`org.apache.jackrabbit.oak.spi.security.authorization.permission` provides some
-extensions points that allow to plug custom extensions or implementations of
-the permission evaluation.
+_todo_ readable tree configuration
-#### Differences wrt Jackrabbit 2.x
-see the corresponding [documentation](permission/differences.html).
+##### Regular Permission Evaluation
+
+see [details](permission/evaluation.html)
#### Permission Representation in the Repository
@@ -135,23 +278,6 @@ _todo_
- * (PATH) protected ABORT
-#### Administrative Access
-In the default implementation following principals always have full access to
-the whole content repository (except for hidden items that are not exposed
-on the Oak API) irrespective of the access control content:
-
-- `SystemPrincipal`
-- All instances of `AdminPrincipal`
-- All principals whose name matches the configured administrative principal names (see Configuration section below). This configuration only applies to the permission evaluation and is currently not reflected in other security models nor methods that deal with the administrator (i.e. `User#isAdmin`).
-
-
-#### Detains on Permission Evaluation
-
-_todo_
-
-see [details](permission/evaluation.html)
-
-
### API Extensions
_todo_
@@ -178,7 +304,12 @@ org.apache.jackrabbit.oak.spi.security.a
| | | | |
-Differences to Jackrabbit 2.x
+##### PARAM_PERMISSIONS_JR2
+
+- `REMOVE_NODE`: if present, the permission evaluation will traverse down the hierarchy upon node removal. This config flag is a best effort approach but doesn't guarantee an identical behavior.
+- `USER_MANAGEMENT`: if set permissions for user related items will be evaluated the same way as regular JCR items irrespective of their protection status.
+
+##### Differences to Jackrabbit 2.x
The `omit-default-permission` configuration option present with the Jackrabbit's AccessControlProvider implementations is no longer supported with Oak.
Since there are no permissions installed by default this flag has become superfluous.
@@ -193,5 +324,7 @@ _todo_
<!-- references -->
-[Permissions]: /oak/docs/apidocs/org/apache/jackrabbit/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.html
+[Permissions]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.html
[AuthorizationConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html
+[OAK-444]: https://issues.apache.org/jira/browse/OAK-444
+[JCR-2963]: https://issues.apache.org/jira/browse/JCR-2963
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/differences.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/differences.md?rev=1595182&r1=1595181&r2=1595182&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/differences.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/differences.md Fri May 16 12:50:12 2014
@@ -20,7 +20,7 @@
_todo_
-##### Permissions
+#### Permissions
The following permissions are now an aggregation of new permissions:
@@ -33,7 +33,7 @@ The following permissions have been intr
- `INDEX_DEFINITION_MANAGEMENT`: permission to create, modify and remove the oak:index node and it's subtree which is expected to contain the index definitions.
-#### Permission Evaluation
+#### Evaluation
##### Reading
@@ -43,16 +43,11 @@ content depends on the read permissions
Jackrabbit 2.x doesn't apply any special rule. These changes are covered by [OAK-444]
and address the concerns summarized in [JCR-2963].
-##### Property Modification
-Since Oak the former `SET_PROPERTY` permission has been split such to allow for
-more fined grained control on writing JCR properties. In particular Oak clearly
-distinguishes between creating a new property that didn't exist before, modifying
-or removing an existing property.
-
##### Node Removal
As of Oak `Node#remove()` only requires sufficient permissions to remove the target
node. In contrast to Jackrabbit 2.x the validation will not traverse the tree and
verify remove permission on all child nodes/properties.
+
In order to obtain backwards compatible behavior with respect to tree removal the
permission evaluation can be configured to traverse down the hierarchy upon removal.
This config flag is a best effort approach but doesn't guarantee an identical behavior.
@@ -66,19 +61,7 @@ the child collection of the parent node)
##### Move
Due to the nature of the diff mechanism in Oak it is no longer possible to treat
-move operations the same way as it was implemented in Jackrabbit 2.x. The current
-permission evaluation attempts to provide a best-effort handling to achieve a
-similar behavior that it was present in Jackrabbit 2.x.
-
-The current implementation has the following limitations with respect to multiple
-move operations within a given set of transient operations:
-
-- Move operations that replace an node that has been moved away will not be
-detected as modification by the diff mechanism and regular permission checks for
-on the subtree will be performed.
-- Moving an ancestor of a node that has been moved will only detect the second
-move and will enforce regular permissions checks on the child that has been moved
-in a first step.
+move operations the same way as it was implemented in Jackrabbit 2.x.
For API consumers and applications running on Jackrabbit Oak this means that
combinations of multiple moves can not always be properly resolved. Consequently
@@ -97,15 +80,11 @@ For backwards compatibility with Jackrab
by setting the corresponding configuration flag.
##### Version Management
-Reading and writing items in the version store does not follow the regular permission
-evaluation but depends on access rights present on the corresponding versionable node.
-In case the version information does no longer have a versionable node in this workspace
-that original path is used to evaluate the effective permissions that would apply
-to that node if the version was restored.
-Note, that as in Jackrabbit VERSION_MANAGEMENT permission instead of the regular
-JCR write permissions is required in order to execute version operations and thus
-modify the version store. These changes are covered by [OAK-444] and address the
-concerns summarized in [JCR-2963].
+Reading items in the version store depends on access rights present on the
+corresponding versionable node. In case the version information does no longer
+have a versionable node in this workspace that original path is used to evaluate
+the effective permissions that would apply to that node if the version was restored.
+This changes is covered by [OAK-444] and addresses concerns summarized in [JCR-2963].
<!-- hidden references -->
[Permissions]: http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md?rev=1595182&r1=1595181&r2=1595182&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md Fri May 16 12:50:12 2014
@@ -22,92 +22,90 @@ Permission Evaluation in Detail
_todo_
-### Overview on Permission Evaluation
+#### Evaluation of Permission Entries
_todo_
-### Administrative Access
+### Overview on Permission Evaluation
+
+#### <a name="SecureNodeBuilder"></a> The SecureNodeBuilder
-_todo_
+ _todo_
+
+#### <a name="getTreePermissions"></a> TreePermissions
+
+ _todo_
+
+
+#### <a name="getEntryIterator"></a> The PermissionEntry Iterator
+
+ _todo_
+
+#### <a name="permissionStore"></a> The Permission Store
+
+ _todo_
+
+#### Reading a Node : Step by Step
+
+The following section describes what happens on `session.getNode("/foo").getProperty("jcr:title")`
+in terms of permission evaluation:
+
+ 1. `SessionImpl.getNode()` internally calls `SessionDelegate.getNode()`
+ which calls `Root.getTree()` which calls `Tree.getTree()` on the `/foo` tree.
+ This creates a bunch of linked `MutableTree` objects.
+ 1. The session delegate then checks if the tree really exists, by calling `Tree.exists()`
+ which then calls `NodeBuilder.exists()`.
-### Individual Permissions in Detail
+ 1. If the session performing the operation is an _admin_ session, then the node builder from
+ the persistence layer is directly used. In all other cases, the original node builder
+ is wrapped by a `SecureNodeBuilder`. The `SecureNodeBuilder` performs permission
+ checks before delegating the calls to the delegated builder.
+
+ 1. For non _admin_ sessions the `SecureNodeBuilder` fetches its _tree permissions_ via
+ `getTreePermissions()` (See [below](#getTreePermissions) of how this works) and then
+ calls `TreePermission.canRead()`. This method (signature with no arguments) checks the
+ `READ_NODE` permission for normal trees (as in this example) or the `READ_ACCESS_CONTROL`
+ permission on _AC trees_ [^1] and remembers the result in the `ReadStatus`.
+
+ For that an iterator of the _permission entries_ is [retrieved](#getEntryIterator) which
+ provides all the relevant permission entries needed to be evaluated for this tree (and
+ and set of principals associated with the permission provider).
+
+ 1. The _permission entries_ are analyzed if they include the respective permission and if so,
+ the read status is set accordingly. Note that the sequence of the permission entries from
+ the iterator is already in the correct order for this kind of evaluation. this is ensured
+ by the way how they are stored in the [permission store](#permissionStore) and how they
+ are feed into the iterator.
+
+ The iteration also detects if the evaluated permission entries cover _this_ node and all
+ its properties. If this is the case, subsequent calls that evaluate the property read
+ permissions would then not need to do the same iteration again. In order to detect this,
+ the iteration checks if a non-matching permission entry or privilege was skipped
+ and eventually sets the respective flag in the `ReadStatus`. This flag indicates if the
+ present permission entries are sufficient to tell if the session is allowed to read
+ _this_ node and all its properties. If there are more entries present than the ones needed
+ for evaluating the `READ_NODE` permission, then it's ambiguous to determine if all
+ properties can be read.
+
+ 1. Once the `ReadStatus` is calculated (or was calculated earlier) the `canRead()` method
+ returns `ReadStatus.allowsThis()` which specifies if _this_ node is allowed to be read.
+
+ [^1]: by default access control content is stored in the `rep:policy` subtree of an access controlled node.
+
+#### Reading an Property : Step by Step
+
+ 1. _todo_
+
+#### Adding a Node : Step by Step
+_todo_
+#### Changing a Property : Step by Step
+_todo_
+#### Locking a Node : Step by Step
+_todo_
+#### Registering a Node Type : Step by Step
+_todo_
-##### Reading
-Due to the fine grained read permissions Oak read access can be separately granted/denied
-for nodes and properties. See also the section about extended [Restriction Management](../accesscontrol/restriction.html).
-Granting the `jcr:read` privilege will result in a backwards compatible
-read access for nodes and their properties, while specifying `rep:readNodes` or
-`rep:readProperties` privileges allows separately granting or denying access to
-nodes and properties (see also [Privilege Management](../privilege.html) for changes
-in the privilege definitions).
-Together with the restrictions this new behavior now allows to individually grant/deny
-access to properties that match a given name/path/nodetype (and as a possible extension even property value).
-
-The only break in terms of backwards compatibility is the accessibility of version
-content underneath `/jcr:system/jcr:versionStore`. As of Oak the access to version
-content depends on the read permissions present with the versionable node while
-Jackrabbit 2.x doesn't apply any special rule. These changes are covered by [OAK-444]
-and address the concerns summarized in [JCR-2963].
-
-##### Property Modification
-Since Oak the former `SET_PROPERTY` permission has been split such to allow for more fined grained control on writing JCR properties. In particular Oak clearly distinguishes between creating a new property that didn't exist before, modifying or removing an existing property.
-This will allow to cover those cases where a given subject is only allowed to create content but doesn't have the ability to modify/delete it later on.
-
-##### Node Removal
-As of Oak `Node#remove()` only requires sufficient permissions to remove the target node. In contrast to Jackrabbit 2.x the validation will not traverse the tree and verify remove permission on all child nodes/properties.
-In order to obtain backwards compatible behavior with respect to tree removal the permission evaluation can be configured to traverse down the hierarchy upon removal. This config flag is a best effort approach but doesn't guarantee an identical behavior.
-
-##### Rename
-Due to the nature of the diff mechanism in Oak it is not possible to distinguish
-between `JackrabbitNode#rename` and a move with subsequent reordering. Consequently
-the permission evaluation will no longer apply the special handling for the renaming
-as it was present in Jackrabbit 2.x (renaming just required the ability to modify
-the child collection of the parent node).
-
-##### Move
-Due to the nature of the diff mechanism in Oak it is no longer possible to treat
-move operations the same way as it was implemented in Jackrabbit 2.x. The current
-permission evaluation attempts to provide a best-effort handling to achieve a
-similar behavior that it was present in Jackrabbit 2.x.
-
-The current implementation has the following limitations with respect to multiple
-move operations within a given set of transient operations:
-
-- Move operations that replace an node that has been moved away will not be
-detected as modification by the diff mechanism and regular permission checks for
-on the subtree will be performed.
-- Moving an ancestor of a node that has been moved will only detect the second
-move and will enforce regular permissions checks on the child that has been moved
-in a first step.
-
-For API consumers and applications running on Jackrabbit Oak this means that
-combinations of multiple moves can not always be properly resolved. Consequently
-permissions will be evaluated as if the modifications did not include move
-(in general being more restrictive): If the move leads to changes that are detected
-by the diff mechanism, regular permissions will be evaluated for all items that
-appear to be added, removed or modified, while a regular move operations just
-requires `REMOVE_NODE` permission on the source, `ADD_NODE` and `NODE_TYPE_MANAGEMENT`
-permissions at the destination.
-
-##### User Management
-By default user management operations require the specific user mgt related permission to be granted for the editing subject. This permission (including a corresponding privilege) has been introduced with Oak 1.0.
-For backwards compatibility with Jackrabbit 2.x this behavior can be turned off by setting the corresponding configuration flag.
-
-##### Version Management
-Reading and writing items in the version store does not follow the regular permission evaluation but depends on access rights present on the corresponding versionable node. In case the version information does no longer have a versionable node in this workspace that original path is used to evaluate the effective permissions that would apply to that node if the version was restored.
-Note, that as in Jackrabbit VERSION_MANAGEMENT permission instead of the regular JCR write permissions is required in order to execute version operations and thus modify the version store. These changes are covered by [OAK-444] and address the concerns summarized in [JCR-2963].
-
-##### Query Index Definitions
-Writing query index definitions requires the specific index definition management
-which is enforce on nodes named "oak:index" and the subtree defined by them.
-Note that the corresponding items are not protected in the JCR sense. Consequently
-any other modification in these subtrees like e.g. changing the primary type
-or adding mixin types is governed by the corresponding privileges.
-
-
-<!-- hidden references -->
-[OAK-444]: https://issues.apache.org/jira/browse/OAK-444
-[JCR-2963]: https://issues.apache.org/jira/browse/JCR-2963
\ No newline at end of file
+<!-- hidden references -->
\ No newline at end of file