[
https://issues.apache.org/jira/browse/OAK-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Adamcin updated OAK-10424:
-------------------------------
Description:
Setting the global QueryEngineSettingsService.getFastQuerySize() value to true
is currently the only way to allow service users to leverage JCR query for
collecting accurate repository count metrics in a performant way. However,
doing so in a multiuser repository may be inadvisable because the fast result
size is returned to the caller without considering the caller's read
permissions over the paths returned in the result, which may allow less
privileged users to discover the presence of nodes that are not otherwise
visible to them.
See [https://jackrabbit.apache.org/oak/docs/query/query-engine.html#result-size]
As an alternative to the global setting, Oak should provide a query option
alongside [TRAVERSAL, OFFSET / LIMIT, and INDEX
TAG|https://jackrabbit.apache.org/oak/docs/query/query-engine.html#query-options],
such as "INSECURE RESULT SIZE" .
Similarly, IndexDefinition.SecureFacetConfiguration.MODE.INSECURE (insecure
facets) can provide extremely valuable counts for property value distribution
in large repositories. At the moment, it can only be defined on an index
definition, even though it governs the facet counts at query time and has no
effect on the persisted content of the index at all. Like fastQuerySize, Oak
should provide a query option such as "INSECURE FACETS", for permitted system
users to leverage insecure facets even when the query execution plan uses an
index definition that only allows secure or statistical facet security.
For example,
select a.[jcr:path] from [nt:base] as a where contains(a.[text], 'Hello World')
option(insecure result size, insecure facets, offset 10)
To address the security risk, the application should also provide a
configuration of some kind to restrict the ability to effectively leverage this
option to permitted system users, which could be implemented as a JCR
repository privilege or an allowlist property in the QueryEngineSettingsService
configuration.
I have provided a PR that adds support for an INSECURE RESULT SIZE query option
and an INSECURE FACETS query option, as well as an "rep:insecureQueryOptions"
repository privilege. I think the JCR privilege-based approach for
configuration of this permission is more aligned with how system users are
defined in practice, but this approach requires a minor version increase in the
following oak-security-spi packages:
* org.apache.jackrabbit.oak.spi.security.authorization.permission
* org.apache.jackrabbit.oak.spi.security.privilege
Because all registered permissions are serialized into a long bitset, there is
clearly a premium on adding another built-in privilege, so I figured that it
would be better to choose a name for the privilege that would make it
applicable to both of these new options, and any future query options that may
involve a tradeoff between security and performance.
was:
Setting the global QueryEngineSettingsService.getFastQuerySize() value to true
is currently the only way to allow service users to leverage JCR query for
collecting accurate repository count metrics in a performant way. However,
doing so in a multiuser repository may be inadvisable because the fast result
size is returned to the caller without considering the caller's read
permissions over the paths returned in the result, which may allow less
privileged users to discover the presence of nodes that are not otherwise
visible to them.
See [https://jackrabbit.apache.org/oak/docs/query/query-engine.html#result-size]
As an alternative to the global setting, Oak should provide a query option
alongside [TRAVERSAL, OFFSET / LIMIT, and INDEX
TAG|https://jackrabbit.apache.org/oak/docs/query/query-engine.html#query-options],
such as "INSECURE RESULTSIZE" .
Similarly, IndexDefinition.SecureFacetConfiguration.MODE.INSECURE (insecure
facets) can provide extremely valuable counts for property value distribution
in large repositories. At the moment, it can only be defined on an index
definition, even though it governs the facet counts at query time and has no
effect on the persisted content of the index at all. Like fastQuerySize, Oak
should provide a query option such as "INSECURE FACETS", for permitted system
users to leverage insecure facets even when the query execution plan uses an
index definition that only allows secure or statistical facet security.
For example,
select a.[jcr:path] from [nt:base] as a where contains(a.[text], 'Hello World')
option(insecure resultsize facets, offset 10)
To address the security risk, the application should also provide a
configuration of some kind to restrict the ability to effectively leverage this
option to permitted system users, which could be implemented as a JCR
repository privilege or an allowlist property in the QueryEngineSettingsService
configuration.
I have provided a PR that adds support for an INSECURE RESULTSIZE query option
and an INSECURE FACETS query option (combined as INSECURE RESULTSIZE FACETS),
as well as an "rep:insecureQueryOptions" repository privilege. I think the JCR
privilege-based approach for configuration of this permission is more aligned
with how system users are defined in practice, but this approach requires a
minor version increase in the following oak-security-spi packages:
* org.apache.jackrabbit.oak.spi.security.authorization.permission
* org.apache.jackrabbit.oak.spi.security.privilege
Because all registered permissions are serialized into a long bitset, there is
clearly a premium on adding another built-in privilege, so I figured that it
would be better to choose a name for the privilege that would make it
applicable to both of these new options, and any future query options that may
involve a tradeoff between security and performance.
> Allow Fast Query Size and Insecure Facets to be selectively enabled with
> query options for permitted principals
> ----------------------------------------------------------------------------------------------------------------
>
> Key: OAK-10424
> URL: https://issues.apache.org/jira/browse/OAK-10424
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Affects Versions: 1.56.0
> Reporter: Mark Adamcin
> Priority: Major
> Labels: query
>
> Setting the global QueryEngineSettingsService.getFastQuerySize() value to
> true is currently the only way to allow service users to leverage JCR query
> for collecting accurate repository count metrics in a performant way.
> However, doing so in a multiuser repository may be inadvisable because the
> fast result size is returned to the caller without considering the caller's
> read permissions over the paths returned in the result, which may allow less
> privileged users to discover the presence of nodes that are not otherwise
> visible to them.
> See
> [https://jackrabbit.apache.org/oak/docs/query/query-engine.html#result-size]
> As an alternative to the global setting, Oak should provide a query option
> alongside [TRAVERSAL, OFFSET / LIMIT, and INDEX
> TAG|https://jackrabbit.apache.org/oak/docs/query/query-engine.html#query-options],
> such as "INSECURE RESULT SIZE" .
> Similarly, IndexDefinition.SecureFacetConfiguration.MODE.INSECURE (insecure
> facets) can provide extremely valuable counts for property value distribution
> in large repositories. At the moment, it can only be defined on an index
> definition, even though it governs the facet counts at query time and has no
> effect on the persisted content of the index at all. Like fastQuerySize, Oak
> should provide a query option such as "INSECURE FACETS", for permitted system
> users to leverage insecure facets even when the query execution plan uses an
> index definition that only allows secure or statistical facet security.
> For example,
> select a.[jcr:path] from [nt:base] as a where contains(a.[text], 'Hello
> World') option(insecure result size, insecure facets, offset 10)
> To address the security risk, the application should also provide a
> configuration of some kind to restrict the ability to effectively leverage
> this option to permitted system users, which could be implemented as a JCR
> repository privilege or an allowlist property in the
> QueryEngineSettingsService configuration.
> I have provided a PR that adds support for an INSECURE RESULT SIZE query
> option and an INSECURE FACETS query option, as well as an
> "rep:insecureQueryOptions" repository privilege. I think the JCR
> privilege-based approach for configuration of this permission is more aligned
> with how system users are defined in practice, but this approach requires a
> minor version increase in the following oak-security-spi packages:
> * org.apache.jackrabbit.oak.spi.security.authorization.permission
> * org.apache.jackrabbit.oak.spi.security.privilege
> Because all registered permissions are serialized into a long bitset, there
> is clearly a premium on adding another built-in privilege, so I figured that
> it would be better to choose a name for the privilege that would make it
> applicable to both of these new options, and any future query options that
> may involve a tradeoff between security and performance.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
