[jira] [Commented] (OAK-8027) Extract public utility for handling jcr:all privilege bits
[
https://issues.apache.org/jira/browse/OAK-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760813#comment-16760813
]
angela commented on OAK-8027:
-
[~stillalex], proposed patch (and one for the tests) attached. wdyt?
> Extract public utility for handling jcr:all privilege bits
> --
>
> Key: OAK-8027
> URL: https://issues.apache.org/jira/browse/OAK-8027
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-8027-tests.patch, OAK-8027.patch
>
>
> [~stillalex], while working on authorization related PoC i found myself
> copying the logic used inside _oak-core_ to store the {{PrivilegeBits}}
> representation of {{jcr:all}}. Since that latter is defined to always reflect
> the aggregation of all registered privileges, which may change over time, the
> code in _oak-core_ uses a placeholder value instead. That logic could be
> shared by different implementations if it was available in _oak-security-spi_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8027) Extract public utility for handling jcr:all privilege bits
[
https://issues.apache.org/jira/browse/OAK-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8027:
Attachment: OAK-8027.patch
OAK-8027-tests.patch
> Extract public utility for handling jcr:all privilege bits
> --
>
> Key: OAK-8027
> URL: https://issues.apache.org/jira/browse/OAK-8027
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-8027-tests.patch, OAK-8027.patch
>
>
> [~stillalex], while working on authorization related PoC i found myself
> copying the logic used inside _oak-core_ to store the {{PrivilegeBits}}
> representation of {{jcr:all}}. Since that latter is defined to always reflect
> the aggregation of all registered privileges, which may change over time, the
> code in _oak-core_ uses a placeholder value instead. That logic could be
> shared by different implementations if it was available in _oak-security-spi_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8027) Extract public utility for handling jcr:all privilege bits
angela created OAK-8027:
---
Summary: Extract public utility for handling jcr:all privilege bits
Key: OAK-8027
URL: https://issues.apache.org/jira/browse/OAK-8027
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security-spi
Reporter: angela
Assignee: angela
[~stillalex], while working on authorization related PoC i found myself copying
the logic used inside _oak-core_ to store the {{PrivilegeBits}} representation
of {{jcr:all}}. Since that latter is defined to always reflect the aggregation
of all registered privileges, which may change over time, the code in
_oak-core_ uses a placeholder value instead. That logic could be shared by
different implementations if it was available in _oak-security-spi_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8026) Warn message when branch is created
Marcel Reutegger created OAK-8026:
-
Summary: Warn message when branch is created
Key: OAK-8026
URL: https://issues.apache.org/jira/browse/OAK-8026
Project: Jackrabbit Oak
Issue Type: Bug
Components: documentmk
Affects Versions: 1.10.0
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Fix For: 1.12
The JournalDiffLoader may log a warn message when a branch is created. This can
be reproduced e.g. with the test
{{DocumentNodeStoreBranchTest#branchedBranch}}. The unit-tests.log then
contains messages like this:
{noformat}
Missing journal entry for b1-0168bdea4d8f-
{noformat}
The JournalDiffLoader considers it missing because the in-memory branch already
contains a reference to this branch revision, even though it hasn't yet been
written.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
[
https://issues.apache.org/jira/browse/OAK-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8023:
Fix Version/s: 1.11.0
1.12
> AccessControlManagerImpl can not handle repository level when editing
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8025) Improve branch state comparison
Marcel Reutegger created OAK-8025: - Summary: Improve branch state comparison Key: OAK-8025 URL: https://issues.apache.org/jira/browse/OAK-8025 Project: Jackrabbit Oak Issue Type: Improvement Components: documentmk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.12 Comparing the head of a branch state with revision brX-0-1 with the equivalent trunk state rX-0-1 may lookup changes in the diff cache even though it could tell from the revision itself that there are no changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
[
https://issues.apache.org/jira/browse/OAK-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-8023:
---
Assignee: angela
> AccessControlManagerImpl can not handle repository level when editing
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
[
https://issues.apache.org/jira/browse/OAK-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760787#comment-16760787
]
angela commented on OAK-8023:
-
[~stillalex], proposed patch attached. let me know if you have a better value
for the repository-path-marker constant i did try empty string to keep it
the same as before but that doesn't work for the odd conversion (see above).
> AccessControlManagerImpl can not handle repository level when editing
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Priority: Minor
> Attachments: OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
[
https://issues.apache.org/jira/browse/OAK-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8023:
Attachment: OAK-8023.patch
> AccessControlManagerImpl can not handle repository level when editing
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Priority: Minor
> Attachments: OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8024) oak-http generates invalid html
Ruben Reusser created OAK-8024: -- Summary: oak-http generates invalid html Key: OAK-8024 URL: https://issues.apache.org/jira/browse/OAK-8024 Project: Jackrabbit Oak Issue Type: Bug Components: oak-http Reporter: Ruben Reusser Attachments: oak-http-fixes.patch when using oak-http to explore a repository invalid html is rendered. The title tag is rendered as causing the generated html to be invalid. This is due to a depricated api usage in oak-http please find attached a patch for this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7997) Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
[
https://issues.apache.org/jira/browse/OAK-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760757#comment-16760757
]
angela commented on OAK-7997:
-
[~tmueller], i used the existing logic that is used in {{SelectorImpl}} to
retrieve the tree object. I had to read that one twice as well and found it a
bit brittle but didn't want to start changing unrelated code that i don't
own... instead attempted to incorporate the fix into the existing logic :-).
let me know if i should change the overall logic...
> Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
> --
>
> Key: OAK-7997
> URL: https://issues.apache.org/jira/browse/OAK-7997
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query, security
>Affects Versions: 1.10.0, 1.8.10
>Reporter: Søren Jensen
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-7997.patch, OAK-7997_2.patch, OAK-7997_3.patch
>
>
> Using Jackrabbit Oak, I've been attempting to configure security through
> {{SecurityProvider}} and {{SecurityConfiguration's. In particular, I've been
> using the restrictions which generally works as expected. However, when
> dealing with JCR-SQL2}} queries, more gets filtered out than expected.
> *Details*
> It can be reproduced with the repository below.
> {code:java}
> /
> node [nt:unstructured]
> subnode [nt:unstructured] {code}
> On {{node}}, I add an access control entry with privilege {{JCR_ALL}} for
> "{{user"}} together with a restriction for {{rep:glob}} -> {{""}}, such that
> {{user}} do not have access to any children of {{node - in this case, only
> subnode}}.
> It works as expected when using {{session.getNode}}:
> * {{session.getNode("/node")}} returns the node
> * {{session.getNode("/node/subnode")}} throws {{PathNotFoundException}} as
> expected due to the restriction.
> However, when I execute the following {{JCR-SQL2}} query:
> {code:java}
> SELECT * FROM [nt:unstructured]{code}
> I get *no results back*. Here I would have expected to get {{/node}}, as it
> is otherwise available when using {{session.getNode}}. Removing the
> restriction yields the expected result of both _/node_ and _/node/subnode_.
> As discussed with [~anchela] on the _users_ mailing list, this may either be
> an actual bug, or it is a conscious decision - in which case it would be nice
> to have it documented for the security.
> *Code for reproducing:*
> The code for reproducing the error is shown below. The "_restrictions"_ map
> below seems to be the problem, as this is what results in both _/node_ and
> _/node/subnode_ being filtered out.
>
> {code:java}
> public static void main(String[] args) throws Exception {
> Repository repository = new Jcr().with(new
> MySecurityProvider()).createRepository();
> Session session = repository.login(new UserIdCredentials(""));//
> principal is "SystemPrincipal.INSTANCE"
> // Create nodes
> Node node = session.getRootNode().addNode("node", "nt:unstructured");
> node.addNode("subnode", "nt:unstructured");
> // Add access control entry + restriction
> AccessControlManager acm = session.getAccessControlManager();
> JackrabbitAccessControlList acl = (JackrabbitAccessControlList) acm
> .getApplicablePolicies("/node").nextAccessControlPolicy();
> Privilege[] privileges = new
> Privilege[]{acm.privilegeFromName(Privilege.JCR_ALL)};
> Map restrictions = new HashMap()
> {{put("rep:glob", new StringValue(""));}};
> acl.addEntry(new PrincipalImpl("user"), privileges, true, restrictions);
> acm.setPolicy("/node", acl);
> session.save();
> // executes query
> RowIterator rows = repository.login(new
> UserIdCredentials("user")).getWorkspace().getQueryManager()
> .createQuery("SELECT * FROM [nt:unstructured]",
> Query.JCR_SQL2).execute().getRows();
> System.out.println("Number of rows: " + rows.getSize()); //Prints 0
> }
> {code}
> *Code for security configuration:*
> The above code makes use of "MySecurityProvider". I do not suspect this to be
> the root cause, but please let me know if it can be helpful to have. The
> security provider has the configuration set to
> "ConfigurationParameters.EMPTY", and it uses all the default implementations
> present within the Jackrabbit Oak project. The only exception is the
> _AuthenticationConfiguration_ which uses a custom implementation using
> pre-authentication:
>
> {code:java}
> class MyAuthenticationConfiguration extends AuthenticationConfigurationImpl {
> public MyAuthenticationConfiguration(SecurityProvider securityProvider) {
> super(securityProvider);
> }
> @NotNull
> @Override
> public Log
[jira] [Commented] (OAK-7947) Lazy loading of Lucene index files startup
[ https://issues.apache.org/jira/browse/OAK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760701#comment-16760701 ] Thomas Mueller commented on OAK-7947: - > Would it be feasible to add a way for users to trigger downloading of indexes? [~mduerig] yes, we can add something like this. One idea is to load all indexes except those marked as deprecated, or we can add a new flag (e.g. "lazyLoad"). I suggest we wait with this until lazy loading works as expected, so that we are sure it works as expected. (If we add such a feature very early on, there is a risk that lazy loading isn't well tested on real problems, as it's rare. I'm not suggesting we don't add unit tests, but here it's a bit hard to come up with unit tests that match reality.) > Lazy loading of Lucene index files startup > -- > > Key: OAK-7947 > URL: https://issues.apache.org/jira/browse/OAK-7947 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12 > > Attachments: OAK-7947.patch, OAK-7947_v2.patch, OAK-7947_v3.patch, > OAK-7947_v4.patch, OAK-7947_v5.patch, lucene-index-open-access.zip > > > Right now, all Lucene index binaries are loaded on startup (I think when the > first query is run, to do cost calculation). This is a performance problem if > the index files are large, and need to be downloaded from the data store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7947) Lazy loading of Lucene index files startup
[
https://issues.apache.org/jira/browse/OAK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760709#comment-16760709
]
Michael Dürig commented on OAK-7947:
{quote}I suggest we wait with this
{quote}
Ack. I'll bring it up again if and once required.
> Lazy loading of Lucene index files startup
> --
>
> Key: OAK-7947
> URL: https://issues.apache.org/jira/browse/OAK-7947
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12
>
> Attachments: OAK-7947.patch, OAK-7947_v2.patch, OAK-7947_v3.patch,
> OAK-7947_v4.patch, OAK-7947_v5.patch, lucene-index-open-access.zip
>
>
> Right now, all Lucene index binaries are loaded on startup (I think when the
> first query is run, to do cost calculation). This is a performance problem if
> the index files are large, and need to be downloaded from the data store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
angela created OAK-8023:
---
Summary: AccessControlManagerImpl can not handle repository level
when editing policies by principal
Key: OAK-8023
URL: https://issues.apache.org/jira/browse/OAK-8023
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, security
Reporter: angela
[~stillalex], it seems that editing access control by principal in the default
implementation doesn't allow for applying entries to the 'null' path.
initially i thought that we can use an empty string value instead for the
{{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (OAK-7997) Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
[
https://issues.apache.org/jira/browse/OAK-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reopened OAK-7997:
-
Reopening because some changes seem a bit risky to me (possibly a bug / hard to
maintain).
[SelectorImpl.java|http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/SelectorImpl.java?r1=1852758&r2=1852757&pathrev=1852758]
{noformat}
+private LazyValue lastReadOnlyTree;
...
+private LazyValue getReadOnlyTree(@NotNull String path) {
+if (lastReadOnlyTree == null) {
+lastReadOnlyTree = new LazyValue() {
+@Override
+protected Tree createValue() {
+return new
ImmutableRoot(query.getExecutionContext().getBaseState()).getTree(path);
+}
+};
+}
+return lastReadOnlyTree;
+}
{noformat}
The lastReadOnlyTree is initialized lazily (which is fine), but how do we
ensure that the path used to initialize it is the same if the method is called
twice? I mean, if the method is called twice as follows, then the same
LazyValue is returned:
{noformat}
LazyValue t1 = getReadOnlyTree(p1);
LazyValue t2 = getReadOnlyTree(p2);
... now t1 == t2, even if p1 != p2 ...
{noformat}
But maybe I just don't understand the logic... I didn't debug / test it.
> Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
> --
>
> Key: OAK-7997
> URL: https://issues.apache.org/jira/browse/OAK-7997
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query, security
>Affects Versions: 1.10.0, 1.8.10
>Reporter: Søren Jensen
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-7997.patch, OAK-7997_2.patch, OAK-7997_3.patch
>
>
> Using Jackrabbit Oak, I've been attempting to configure security through
> {{SecurityProvider}} and {{SecurityConfiguration's. In particular, I've been
> using the restrictions which generally works as expected. However, when
> dealing with JCR-SQL2}} queries, more gets filtered out than expected.
> *Details*
> It can be reproduced with the repository below.
> {code:java}
> /
> node [nt:unstructured]
> subnode [nt:unstructured] {code}
> On {{node}}, I add an access control entry with privilege {{JCR_ALL}} for
> "{{user"}} together with a restriction for {{rep:glob}} -> {{""}}, such that
> {{user}} do not have access to any children of {{node - in this case, only
> subnode}}.
> It works as expected when using {{session.getNode}}:
> * {{session.getNode("/node")}} returns the node
> * {{session.getNode("/node/subnode")}} throws {{PathNotFoundException}} as
> expected due to the restriction.
> However, when I execute the following {{JCR-SQL2}} query:
> {code:java}
> SELECT * FROM [nt:unstructured]{code}
> I get *no results back*. Here I would have expected to get {{/node}}, as it
> is otherwise available when using {{session.getNode}}. Removing the
> restriction yields the expected result of both _/node_ and _/node/subnode_.
> As discussed with [~anchela] on the _users_ mailing list, this may either be
> an actual bug, or it is a conscious decision - in which case it would be nice
> to have it documented for the security.
> *Code for reproducing:*
> The code for reproducing the error is shown below. The "_restrictions"_ map
> below seems to be the problem, as this is what results in both _/node_ and
> _/node/subnode_ being filtered out.
>
> {code:java}
> public static void main(String[] args) throws Exception {
> Repository repository = new Jcr().with(new
> MySecurityProvider()).createRepository();
> Session session = repository.login(new UserIdCredentials(""));//
> principal is "SystemPrincipal.INSTANCE"
> // Create nodes
> Node node = session.getRootNode().addNode("node", "nt:unstructured");
> node.addNode("subnode", "nt:unstructured");
> // Add access control entry + restriction
> AccessControlManager acm = session.getAccessControlManager();
> JackrabbitAccessControlList acl = (JackrabbitAccessControlList) acm
> .getApplicablePolicies("/node").nextAccessControlPolicy();
> Privilege[] privileges = new
> Privilege[]{acm.privilegeFromName(Privilege.JCR_ALL)};
> Map restrictions = new HashMap()
> {{put("rep:glob", new StringValue(""));}};
> acl.addEntry(new PrincipalImpl("user"), privileges, true, restrictions);
> acm.setPolicy("/node", acl);
> session.save();
> // executes query
> RowIterator rows = repository.login(new
> UserIdCredentials("user")).getWorkspace().getQueryManager()
> .createQuery("SELECT * FROM [nt:unstructured]",
> Query.JCR_SQL2).execute().getRows();
> System.out.pri
[jira] [Commented] (OAK-7997) Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
[
https://issues.apache.org/jira/browse/OAK-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760626#comment-16760626
]
Julian Reschke commented on OAK-7997:
-
[~anchela] - ok - I was just a bit alarmed because it says "major bug". :-)
> Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
> --
>
> Key: OAK-7997
> URL: https://issues.apache.org/jira/browse/OAK-7997
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query, security
>Affects Versions: 1.10.0, 1.8.10
>Reporter: Søren Jensen
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-7997.patch, OAK-7997_2.patch, OAK-7997_3.patch
>
>
> Using Jackrabbit Oak, I've been attempting to configure security through
> {{SecurityProvider}} and {{SecurityConfiguration's. In particular, I've been
> using the restrictions which generally works as expected. However, when
> dealing with JCR-SQL2}} queries, more gets filtered out than expected.
> *Details*
> It can be reproduced with the repository below.
> {code:java}
> /
> node [nt:unstructured]
> subnode [nt:unstructured] {code}
> On {{node}}, I add an access control entry with privilege {{JCR_ALL}} for
> "{{user"}} together with a restriction for {{rep:glob}} -> {{""}}, such that
> {{user}} do not have access to any children of {{node - in this case, only
> subnode}}.
> It works as expected when using {{session.getNode}}:
> * {{session.getNode("/node")}} returns the node
> * {{session.getNode("/node/subnode")}} throws {{PathNotFoundException}} as
> expected due to the restriction.
> However, when I execute the following {{JCR-SQL2}} query:
> {code:java}
> SELECT * FROM [nt:unstructured]{code}
> I get *no results back*. Here I would have expected to get {{/node}}, as it
> is otherwise available when using {{session.getNode}}. Removing the
> restriction yields the expected result of both _/node_ and _/node/subnode_.
> As discussed with [~anchela] on the _users_ mailing list, this may either be
> an actual bug, or it is a conscious decision - in which case it would be nice
> to have it documented for the security.
> *Code for reproducing:*
> The code for reproducing the error is shown below. The "_restrictions"_ map
> below seems to be the problem, as this is what results in both _/node_ and
> _/node/subnode_ being filtered out.
>
> {code:java}
> public static void main(String[] args) throws Exception {
> Repository repository = new Jcr().with(new
> MySecurityProvider()).createRepository();
> Session session = repository.login(new UserIdCredentials(""));//
> principal is "SystemPrincipal.INSTANCE"
> // Create nodes
> Node node = session.getRootNode().addNode("node", "nt:unstructured");
> node.addNode("subnode", "nt:unstructured");
> // Add access control entry + restriction
> AccessControlManager acm = session.getAccessControlManager();
> JackrabbitAccessControlList acl = (JackrabbitAccessControlList) acm
> .getApplicablePolicies("/node").nextAccessControlPolicy();
> Privilege[] privileges = new
> Privilege[]{acm.privilegeFromName(Privilege.JCR_ALL)};
> Map restrictions = new HashMap()
> {{put("rep:glob", new StringValue(""));}};
> acl.addEntry(new PrincipalImpl("user"), privileges, true, restrictions);
> acm.setPolicy("/node", acl);
> session.save();
> // executes query
> RowIterator rows = repository.login(new
> UserIdCredentials("user")).getWorkspace().getQueryManager()
> .createQuery("SELECT * FROM [nt:unstructured]",
> Query.JCR_SQL2).execute().getRows();
> System.out.println("Number of rows: " + rows.getSize()); //Prints 0
> }
> {code}
> *Code for security configuration:*
> The above code makes use of "MySecurityProvider". I do not suspect this to be
> the root cause, but please let me know if it can be helpful to have. The
> security provider has the configuration set to
> "ConfigurationParameters.EMPTY", and it uses all the default implementations
> present within the Jackrabbit Oak project. The only exception is the
> _AuthenticationConfiguration_ which uses a custom implementation using
> pre-authentication:
>
> {code:java}
> class MyAuthenticationConfiguration extends AuthenticationConfigurationImpl {
> public MyAuthenticationConfiguration(SecurityProvider securityProvider) {
> super(securityProvider);
> }
> @NotNull
> @Override
> public LoginContextProvider getLoginContextProvider(ContentRepository
> contentRepository) {
> return new LoginContextProvider() {
> @NotNull
> public LoginContext getLoginContext(Credentials credentials,
> String workspaceName) {
>
[jira] [Commented] (OAK-7997) Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
[
https://issues.apache.org/jira/browse/OAK-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760551#comment-16760551
]
angela commented on OAK-7997:
-
[~reschke], i didn't intend to backport it. i don't consider this a critical
bug and there are definitely ways to work around it (i.e. making sure that
jcr:primaryType property is accessible).
> Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
> --
>
> Key: OAK-7997
> URL: https://issues.apache.org/jira/browse/OAK-7997
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query, security
>Affects Versions: 1.10.0, 1.8.10
>Reporter: Søren Jensen
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-7997.patch, OAK-7997_2.patch, OAK-7997_3.patch
>
>
> Using Jackrabbit Oak, I've been attempting to configure security through
> {{SecurityProvider}} and {{SecurityConfiguration's. In particular, I've been
> using the restrictions which generally works as expected. However, when
> dealing with JCR-SQL2}} queries, more gets filtered out than expected.
> *Details*
> It can be reproduced with the repository below.
> {code:java}
> /
> node [nt:unstructured]
> subnode [nt:unstructured] {code}
> On {{node}}, I add an access control entry with privilege {{JCR_ALL}} for
> "{{user"}} together with a restriction for {{rep:glob}} -> {{""}}, such that
> {{user}} do not have access to any children of {{node - in this case, only
> subnode}}.
> It works as expected when using {{session.getNode}}:
> * {{session.getNode("/node")}} returns the node
> * {{session.getNode("/node/subnode")}} throws {{PathNotFoundException}} as
> expected due to the restriction.
> However, when I execute the following {{JCR-SQL2}} query:
> {code:java}
> SELECT * FROM [nt:unstructured]{code}
> I get *no results back*. Here I would have expected to get {{/node}}, as it
> is otherwise available when using {{session.getNode}}. Removing the
> restriction yields the expected result of both _/node_ and _/node/subnode_.
> As discussed with [~anchela] on the _users_ mailing list, this may either be
> an actual bug, or it is a conscious decision - in which case it would be nice
> to have it documented for the security.
> *Code for reproducing:*
> The code for reproducing the error is shown below. The "_restrictions"_ map
> below seems to be the problem, as this is what results in both _/node_ and
> _/node/subnode_ being filtered out.
>
> {code:java}
> public static void main(String[] args) throws Exception {
> Repository repository = new Jcr().with(new
> MySecurityProvider()).createRepository();
> Session session = repository.login(new UserIdCredentials(""));//
> principal is "SystemPrincipal.INSTANCE"
> // Create nodes
> Node node = session.getRootNode().addNode("node", "nt:unstructured");
> node.addNode("subnode", "nt:unstructured");
> // Add access control entry + restriction
> AccessControlManager acm = session.getAccessControlManager();
> JackrabbitAccessControlList acl = (JackrabbitAccessControlList) acm
> .getApplicablePolicies("/node").nextAccessControlPolicy();
> Privilege[] privileges = new
> Privilege[]{acm.privilegeFromName(Privilege.JCR_ALL)};
> Map restrictions = new HashMap()
> {{put("rep:glob", new StringValue(""));}};
> acl.addEntry(new PrincipalImpl("user"), privileges, true, restrictions);
> acm.setPolicy("/node", acl);
> session.save();
> // executes query
> RowIterator rows = repository.login(new
> UserIdCredentials("user")).getWorkspace().getQueryManager()
> .createQuery("SELECT * FROM [nt:unstructured]",
> Query.JCR_SQL2).execute().getRows();
> System.out.println("Number of rows: " + rows.getSize()); //Prints 0
> }
> {code}
> *Code for security configuration:*
> The above code makes use of "MySecurityProvider". I do not suspect this to be
> the root cause, but please let me know if it can be helpful to have. The
> security provider has the configuration set to
> "ConfigurationParameters.EMPTY", and it uses all the default implementations
> present within the Jackrabbit Oak project. The only exception is the
> _AuthenticationConfiguration_ which uses a custom implementation using
> pre-authentication:
>
> {code:java}
> class MyAuthenticationConfiguration extends AuthenticationConfigurationImpl {
> public MyAuthenticationConfiguration(SecurityProvider securityProvider) {
> super(securityProvider);
> }
> @NotNull
> @Override
> public LoginContextProvider getLoginContextProvider(ContentRepository
> contentRepository) {
> return new LoginContextProvider() {
> @NotNull
>
