[
https://issues.apache.org/jira/browse/OAK-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16748049#comment-16748049
]
angela commented on OAK-7997:
-----------------------------
[~snj], i extracted a test case based on your description (directly operating
on oak QueryEngine and oak API for simplicity) and i added some additional
variants:
a) your case: single policy on /node with single entry + rep:glob restriction
with empty value => unexpected result
b) policy on /node (allow) and another policy on /node/subnode (deny) =>
expected result (but obviously not practical in real life... just for the
limited test-setup that's equivalent)
and while writing the summary i noticed a potential reason for the failure in
a): with the ""-rep:glob we not only deny access to the child node but also to
all properties of /node because the glob restriction is just a simple
path-matching and doesn't differentiate between child properties and child
nodes. to illustrate this (and because I suspect that the query looks at
jcr:primaryType property) i added yet another test case
c) same as a) but additionally granting property-read at /node/jcr:primaryType
=> expected result.
that's just for an initial illustration. i don't think that extra entry should
be needed because in the JCR API implementation in Oak we added some extra
logic to make sure a Node and its primary type information is accessible even
if the {{jcr:primaryType}} property is not. So, with your setup
{{Session.getNode("/node")}} succeeds and I think so does
{{Session.getNode("/node").getPrimaryNodeType()}}. but afaik
{{Session.getNode("/node").getProperty("jcr:primaryType")}} and
{{Session.getProperty("/node/jcr:primaryType")}} will fail because your
test-session doesn't have the ability to read that property because of the
""-glob-restriction.
what i didn't find out until now is where exactly the query engine misses
(skips) the result and if it's really because of the primary-type
property...the only thing i found was
{{org.apache.jackrabbit.oak.query.index.FilterImpl.isAccessible(String path)}}
but somehow i never got there when debugging. that's what i will next (and
reach out to the query team in case i get stuck)... more tomorrow.
> 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
> Priority: Major
> Attachments: OAK-7997.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<String, Value> restrictions = new HashMap<String, Value>()
> {{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) {
> String userId = ((UserIdCredentials) credentials).getUserId();
> Set<Principal> principalSets = new HashSet<>();
> if (userId.isEmpty()) {
> principalSets.add(SystemPrincipal.INSTANCE);
> } else {
> principalSets.add(new PrincipalImpl(userId));
> }
> Map<String, ? extends Principal> publicPrivileges = new
> HashMap<>();
> AuthInfoImpl authInfoImpl = new AuthInfoImpl(userId,
> publicPrivileges, principalSets);
> Subject subject = new Subject(true, principalSets,
> Collections.singleton(authInfoImpl), new HashSet<Principal>());
> return new PreAuthContext(subject);
> }
> };
> }
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
