[jira] [Assigned] (OAK-11111) CachedPrincipalMembershipReader could return empty principal under concurrency
[ https://issues.apache.org/jira/browse/OAK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-1: -- Assignee: Alejandro Moratinos > CachedPrincipalMembershipReader could return empty principal under concurrency > -- > > Key: OAK-1 > URL: https://issues.apache.org/jira/browse/OAK-1 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.68.0 >Reporter: Alejandro Moratinos >Assignee: Alejandro Moratinos >Priority: Major > > CachedPrincipalMembershipReader can be configured to define a stale time > during which an outdated principal list is returned while the cache is being > refreshed. > If a stale time is configured then there will be a period when the cache it's > being updated by one request thread > ([here|https://github.com/apache/jackrabbit-oak/blob/9ca692077b7a8c3f43f42895a4c3ba93d0614011/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/CachedPrincipalMembershipReader.java#L128-L131]) > and others request could serve an empty list of principals because the > property that contains [the cached principal list is not written > yet|https://github.com/apache/jackrabbit-oak/blob/9ca692077b7a8c3f43f42895a4c3ba93d0614011/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/CachedPrincipalMembershipReader.java#L180-L191]. > This can happens depending on the concurrency level and the time it takes > to build the principal list from one thread. > Also that could happen only if the property is not present which could only > occur the first time the cache is being built as the property is not being > deleted afterwards. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-11026) ExternalGroupPrincipalProvider needs to cache results of local group resolution
Angela Schreiber created OAK-11026:
--
Summary: ExternalGroupPrincipalProvider needs to cache results of
local group resolution
Key: OAK-11026
URL: https://issues.apache.org/jira/browse/OAK-11026
Project: Jackrabbit Oak
Issue Type: Improvement
Components: auth-external, core
Reporter: Angela Schreiber
The dynamic sync feature stores the list of external group principal names with
the user account. However, if those external groups are members of local groups
owned by the repository, that inherited group membership is not cached and will
be re-calculated upon subsequent repository logins.
In case of a high number of inherited local groups this can lead to performance
issues upon login and we should leverage the UserConfiguration configuration
parameter PARAM_CACHE_EXPIRATION to also populate the information below
userhome/rep:cache with the result from the group principal resolution from
{{ExternalGroupPrincipalProvider}}.
this should go along with dedicated benchmarks measuring the effect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10956) Improve Row.getPath()
[
https://issues.apache.org/jira/browse/OAK-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867238#comment-17867238
]
Angela Schreiber commented on OAK-10956:
[~joerghoh], i had a quick look and based on my understanding of the code, the
trees are not resolved as part of the getPath call they already got
resolved earlier when building the {{ResultRowImpl}} in the {{RowIterator}}
(QueryImpl line 987)
{code}
ResultRowImpl currentRow() {
int selectorCount = selectors.size();
Tree[] trees = new Tree[selectorCount];
for (int i = 0; i < selectorCount; i++) {
SelectorImpl s = selectors.get(i);
trees[i] = s.currentTree();
}
[...]
{code}
The only benefit of not calling {{Tree.getPath}} would be that the path of a
tree is computed every time the method is called. in other words this is not a
simple reading-property operation.
However, I wonder if it would be possible to load the trees more lazily but
we needed to check that with the indexing experts.
cc: [~fortino], [~thomasm]
> Improve Row.getPath()
> -
>
> Key: OAK-10956
> URL: https://issues.apache.org/jira/browse/OAK-10956
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing, query
>Reporter: Joerg Hoh
>Priority: Major
> Labels: performance
>
> Assuming that I have this code to read just the path of all search results:
> {noformat}
> List foundPaths = new ArrayList<>();
> QueryResult qr = query.execute(...);
> RowIterator iter = qr.getRows();
> while (iter.hasNext) {
> Row r = iter.nextRow();
> foundPaths.add(r.getPath());
> }
> {noformat}
> We have found that {{r.getPath()}} still resolves a {{Tree}}, while
> {{r.getValue("jcr:path").toString()}} returns the same result, but without
> resolving a {{Tree}}.
> I suggest that we change the implementation of {{getPath()}} (without
> parameters) to use the same approach; this would avoid quite some repository
> overhead.
> //CC [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10956) Improve Row.getPath()
[
https://issues.apache.org/jira/browse/OAK-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10956:
---
Component/s: query
> Improve Row.getPath()
> -
>
> Key: OAK-10956
> URL: https://issues.apache.org/jira/browse/OAK-10956
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing, query
>Reporter: Joerg Hoh
>Priority: Major
>
> Assuming that I have this code to read just the path of all search results:
> {noformat}
> List foundPaths = new ArrayList<>();
> QueryResult qr = query.execute(...);
> RowIterator iter = qr.getRows();
> while (iter.hasNext) {
> Row r = iter.nextRow();
> foundPaths.add(r.getPath());
> }
> {noformat}
> We have found that {{r.getPath()}} still resolves a {{Tree}}, while
> {{r.getValue("jcr:path").toString()}} returns the same result, but without
> resolving a {{Tree}}.
> I suggest that we change the implementation of {{getPath()}} (without
> parameters) to use the same approach; this would avoid quite some repository
> overhead.
> //CC [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10956) Improve Row.getPath()
[
https://issues.apache.org/jira/browse/OAK-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10956:
---
Labels: performance (was: )
> Improve Row.getPath()
> -
>
> Key: OAK-10956
> URL: https://issues.apache.org/jira/browse/OAK-10956
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing, query
>Reporter: Joerg Hoh
>Priority: Major
> Labels: performance
>
> Assuming that I have this code to read just the path of all search results:
> {noformat}
> List foundPaths = new ArrayList<>();
> QueryResult qr = query.execute(...);
> RowIterator iter = qr.getRows();
> while (iter.hasNext) {
> Row r = iter.nextRow();
> foundPaths.add(r.getPath());
> }
> {noformat}
> We have found that {{r.getPath()}} still resolves a {{Tree}}, while
> {{r.getValue("jcr:path").toString()}} returns the same result, but without
> resolving a {{Tree}}.
> I suggest that we change the implementation of {{getPath()}} (without
> parameters) to use the same approach; this would avoid quite some repository
> overhead.
> //CC [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10451) UserPrincipalProvider may cause many conflicts when under load
[ https://issues.apache.org/jira/browse/OAK-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854649#comment-17854649 ] Angela Schreiber commented on OAK-10451: [~reschke], sorry for that. i fixed it yesterday. > UserPrincipalProvider may cause many conflicts when under load > -- > > Key: OAK-10451 > URL: https://issues.apache.org/jira/browse/OAK-10451 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, security >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > Fix For: 1.66.0 > > Attachments: LoginTest_20231010_172626_with_patch.csv, > LoginTest_20231010_173013_without_patch.csv > > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. This will result > in thundering herd problem when the system is under load and the expiration > time for the cache is reached. Incoming requests that authenticate > concurrently will all try to refresh the cache and cause conflicts because > each request tries to set a new expiration time that is slightly different > from the others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10451) UserPrincipalProvider may cause many conflicts when under load
[ https://issues.apache.org/jira/browse/OAK-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10451. Fix Version/s: 1.66.0 Resolution: Fixed > UserPrincipalProvider may cause many conflicts when under load > -- > > Key: OAK-10451 > URL: https://issues.apache.org/jira/browse/OAK-10451 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, security >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > Fix For: 1.66.0 > > Attachments: LoginTest_20231010_172626_with_patch.csv, > LoginTest_20231010_173013_without_patch.csv > > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. This will result > in thundering herd problem when the system is under load and the expiration > time for the cache is reached. Incoming requests that authenticate > concurrently will all try to refresh the cache and cause conflicts because > each request tries to set a new expiration time that is slightly different > from the others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-6756) Convert oak-auth-external to OSGi R7 annotations
[ https://issues.apache.org/jira/browse/OAK-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846216#comment-17846216 ] Angela Schreiber commented on OAK-6756: --- [~baedke], sounds like a plan i was on vacation but will try to make time to look at the PR this week. > Convert oak-auth-external to OSGi R7 annotations > > > Key: OAK-6756 > URL: https://issues.apache.org/jira/browse/OAK-6756 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: auth-external >Reporter: Robert Munteanu >Assignee: Manfred Baedke >Priority: Major > Labels: technical_debt > Fix For: 1.64.0 > > Attachments: cschneider-OAK-6756.osgi-diff.txt > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10772) Broken links in authentication documentation
[ https://issues.apache.org/jira/browse/OAK-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10772. Fix Version/s: 1.64.0 Resolution: Fixed > Broken links in authentication documentation > > > Key: OAK-10772 > URL: https://issues.apache.org/jira/browse/OAK-10772 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.64.0 > > > i noticed a few broken links in the authentication related documentation, > notably in > - authentication/default.md > - authentication/tokenmanagement.md -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10772) Broken links in authentication documentation
Angela Schreiber created OAK-10772: -- Summary: Broken links in authentication documentation Key: OAK-10772 URL: https://issues.apache.org/jira/browse/OAK-10772 Project: Jackrabbit Oak Issue Type: Documentation Components: doc Reporter: Angela Schreiber Assignee: Angela Schreiber i noticed a few broken links in the authentication related documentation, notably in - authentication/default.md - authentication/tokenmanagement.md -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10738) Add default values to user-sync configuration section
[
https://issues.apache.org/jira/browse/OAK-10738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10738.
Fix Version/s: 1.62.0
Resolution: Fixed
pushed the fix and will try to deploy the site later today.
> Add default values to user-sync configuration section
> --
>
> Key: OAK-10738
> URL: https://issues.apache.org/jira/browse/OAK-10738
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: doc
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.62.0
>
>
> the documentation for the external user sync feature does not list the
> default values of the configuration options at
> [https://jackrabbit.apache.org/oak/docs/security/authentication/external/defaultusersync.html#Configuration]
> in addition the table is missing the {{enableRFC7613UsercaseMappedProfile}}
> option both for users and groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10738) Add default values to user-sync configuration section
[
https://issues.apache.org/jira/browse/OAK-10738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10738:
---
Description:
the documentation for the external user sync feature does not list the default
values of the configuration options at
[https://jackrabbit.apache.org/oak/docs/security/authentication/external/defaultusersync.html#Configuration]
in addition the table is missing the {{enableRFC7613UsercaseMappedProfile}}
option both for users and groups.
was:the documentation for the external user sync feature does not list the
default values of the configuration options at
https://jackrabbit.apache.org/oak/docs/security/authentication/external/defaultusersync.html#Configuration
> Add default values to user-sync configuration section
> --
>
> Key: OAK-10738
> URL: https://issues.apache.org/jira/browse/OAK-10738
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: doc
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
>
> the documentation for the external user sync feature does not list the
> default values of the configuration options at
> [https://jackrabbit.apache.org/oak/docs/security/authentication/external/defaultusersync.html#Configuration]
> in addition the table is missing the {{enableRFC7613UsercaseMappedProfile}}
> option both for users and groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10738) Add default values to user-sync configuration section
Angela Schreiber created OAK-10738: -- Summary: Add default values to user-sync configuration section Key: OAK-10738 URL: https://issues.apache.org/jira/browse/OAK-10738 Project: Jackrabbit Oak Issue Type: Documentation Components: doc Reporter: Angela Schreiber Assignee: Angela Schreiber the documentation for the external user sync feature does not list the default values of the configuration options at https://jackrabbit.apache.org/oak/docs/security/authentication/external/defaultusersync.html#Configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-10451) UserPrincipalProvider may cause many conflicts when under load
[ https://issues.apache.org/jira/browse/OAK-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reopened OAK-10451: > UserPrincipalProvider may cause many conflicts when under load > -- > > Key: OAK-10451 > URL: https://issues.apache.org/jira/browse/OAK-10451 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, security >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > Attachments: LoginTest_20231010_172626_with_patch.csv, > LoginTest_20231010_173013_without_patch.csv > > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. This will result > in thundering herd problem when the system is under load and the expiration > time for the cache is reached. Incoming requests that authenticate > concurrently will all try to refresh the cache and cause conflicts because > each request tries to set a new expiration time that is slightly different > from the others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-6756) Convert oak-auth-external to OSGi R7 annotations
[ https://issues.apache.org/jira/browse/OAK-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17826052#comment-17826052 ] Angela Schreiber commented on OAK-6756: --- [~baedke] , ack. thanks for the information > Convert oak-auth-external to OSGi R7 annotations > > > Key: OAK-6756 > URL: https://issues.apache.org/jira/browse/OAK-6756 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: auth-external >Reporter: Robert Munteanu >Assignee: Manfred Baedke >Priority: Major > Labels: technical_debt > Attachments: cschneider-OAK-6756.osgi-diff.txt > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-6756) Convert oak-auth-external to OSGi R7 annotations
[ https://issues.apache.org/jira/browse/OAK-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825684#comment-17825684 ] Angela Schreiber commented on OAK-6756: --- [~baedke] , of course i don't mind, i would even be happy if it got addressed. see above for an issue i spotted when using the patch for oak-exercise. btw: the ldap module also waits to be migrated if you have capacity that would be really appreciated. > Convert oak-auth-external to OSGi R7 annotations > > > Key: OAK-6756 > URL: https://issues.apache.org/jira/browse/OAK-6756 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: auth-external >Reporter: Robert Munteanu >Assignee: Angela Schreiber >Priority: Major > Labels: technical_debt > Attachments: cschneider-OAK-6756.osgi-diff.txt > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10424) Allow Fast Query Size and Insecure Facets to be selectively enabled with query options for permitted principals
[ https://issues.apache.org/jira/browse/OAK-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10424. Fix Version/s: 1.62.0 Resolution: Fixed hi [~madamcin] , i took the liberty to assign this ticket to you since you have worked on it through multiple iterations. thanks a lot for this contribution! i am going to resolve the ticket now that the changes are merged and resolve the ticket. i am very much looking forward to your next contrib. > 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 >Assignee: Mark Adamcin >Priority: Major > Labels: query > Fix For: 1.62.0 > > > 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)
[jira] [Assigned] (OAK-10424) Allow Fast Query Size and Insecure Facets to be selectively enabled with query options for permitted principals
[ https://issues.apache.org/jira/browse/OAK-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10424: -- Assignee: Mark Adamcin > 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 >Assignee: 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)
[jira] [Resolved] (OAK-10572) Best Practices: Clarify ac setup for non existing principals
[ https://issues.apache.org/jira/browse/OAK-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10572. Fix Version/s: 1.60.0 Resolution: Fixed > Best Practices: Clarify ac setup for non existing principals > > > Key: OAK-10572 > URL: https://issues.apache.org/jira/browse/OAK-10572 > Project: Jackrabbit Oak > Issue Type: Task > Components: doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.60.0 > > > the best practices at > [https://jackrabbit.apache.org/oak/docs/security/authentication/external/bestpractices.html] > should clarify how to configure oak such that access control setup for > non-existing external principals is possible and link to the corresponding > statements in sling repo-init. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10572) Best Practices: Clarify ac setup for non existing principals
[ https://issues.apache.org/jira/browse/OAK-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10572: --- Summary: Best Practices: Clarify ac setup for non existing principals (was: ExternalAuth Best Practices: Clarify ac setup for non existing principals) > Best Practices: Clarify ac setup for non existing principals > > > Key: OAK-10572 > URL: https://issues.apache.org/jira/browse/OAK-10572 > Project: Jackrabbit Oak > Issue Type: Task > Components: doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > the best practices at > [https://jackrabbit.apache.org/oak/docs/security/authentication/external/bestpractices.html] > should clarify how to configure oak such that access control setup for > non-existing external principals is possible and link to the corresponding > statements in sling repo-init. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10572) ExternalAuth Best Practices: Clarify ac setup for non existing principals
Angela Schreiber created OAK-10572: -- Summary: ExternalAuth Best Practices: Clarify ac setup for non existing principals Key: OAK-10572 URL: https://issues.apache.org/jira/browse/OAK-10572 Project: Jackrabbit Oak Issue Type: Task Components: doc Reporter: Angela Schreiber Assignee: Angela Schreiber the best practices at [https://jackrabbit.apache.org/oak/docs/security/authentication/external/bestpractices.html] should clarify how to configure oak such that access control setup for non-existing external principals is possible and link to the corresponding statements in sling repo-init. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10563) Document mapping of actions to privileges
[ https://issues.apache.org/jira/browse/OAK-10563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10563. Fix Version/s: 1.60.0 Resolution: Done > Document mapping of actions to privileges > - > > Key: OAK-10563 > URL: https://issues.apache.org/jira/browse/OAK-10563 > Project: Jackrabbit Oak > Issue Type: Wish > Components: doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.60.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10563) Document mapping of actions to privileges
Angela Schreiber created OAK-10563: -- Summary: Document mapping of actions to privileges Key: OAK-10563 URL: https://issues.apache.org/jira/browse/OAK-10563 Project: Jackrabbit Oak Issue Type: Wish Components: doc Reporter: Angela Schreiber Assignee: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10540) Benchmark results V2
Angela Schreiber created OAK-10540: -- Summary: Benchmark results V2 Key: OAK-10540 URL: https://issues.apache.org/jira/browse/OAK-10540 Project: Jackrabbit Oak Issue Type: Technical task Reporter: Angela Schreiber [~nscendoni] , with the new approach in the PR i believe we should re-run our benchmarks to verify if we don't introduce any performance regressions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10525) DefaultSyncContext.createValues : return value should be annotated with @NotNull
[
https://issues.apache.org/jira/browse/OAK-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10525.
Fix Version/s: 1.60.0
Assignee: Angela Schreiber
Resolution: Fixed
> DefaultSyncContext.createValues : return value should be annotated with
> @NotNull
>
>
> Key: OAK-10525
> URL: https://issues.apache.org/jira/browse/OAK-10525
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Trivial
> Fix For: 1.60.0
>
>
> the return value of {{DefaultSyncContext.createValues}} is currently
> annotated with {{@Nullable}} but neither the returned array nor it's values
> are ever null and thus annotation {{@NotNull}} would be more appropriate IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10517) Consistently clean membership when switch between default and dynamic sync
[ https://issues.apache.org/jira/browse/OAK-10517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10517. Fix Version/s: 1.60.0 Resolution: Fixed > Consistently clean membership when switch between default and dynamic sync > --- > > Key: OAK-10517 > URL: https://issues.apache.org/jira/browse/OAK-10517 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.60.0 > > > When dynamic sync is turned on for an existing oak repository any group > membership previously synchronized with the default sync context will be > clean up to comply with the new dynamic representation. However, this only > works for the first switch. If the configuration is switched back to default > and again to dynamic, the cleanup will be skipped. > cc: [~nscendoni] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10451) UserPrincipalProvider may cause many conflicts when under load
[ https://issues.apache.org/jira/browse/OAK-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10451: --- Fix Version/s: 1.60.0 > UserPrincipalProvider may cause many conflicts when under load > -- > > Key: OAK-10451 > URL: https://issues.apache.org/jira/browse/OAK-10451 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, security >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > Fix For: 1.60.0 > > Attachments: LoginTest_20231010_172626_with_patch.csv, > LoginTest_20231010_173013_without_patch.csv > > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. This will result > in thundering herd problem when the system is under load and the expiration > time for the cache is reached. Incoming requests that authenticate > concurrently will all try to refresh the cache and cause conflicts because > each request tries to set a new expiration time that is slightly different > from the others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10525) DefaultSyncContext.createValues : return value should be annotated with @NotNull
Angela Schreiber created OAK-10525:
--
Summary: DefaultSyncContext.createValues : return value should be
annotated with @NotNull
Key: OAK-10525
URL: https://issues.apache.org/jira/browse/OAK-10525
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-external
Reporter: Angela Schreiber
the return value of {{DefaultSyncContext.createValues}} is currently annotated
with {{@Nullable}} but neither the returned array nor it's values are ever null
and thus annotation {{@NotNull}} would be more appropriate IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10517) Consistently clean membership when switch between default and dynamic sync
Angela Schreiber created OAK-10517: -- Summary: Consistently clean membership when switch between default and dynamic sync Key: OAK-10517 URL: https://issues.apache.org/jira/browse/OAK-10517 Project: Jackrabbit Oak Issue Type: Bug Components: auth-external Reporter: Angela Schreiber Assignee: Angela Schreiber When dynamic sync is turned on for an existing oak repository any group membership previously synchronized with the default sync context will be clean up to comply with the new dynamic representation. However, this only works for the first switch. If the configuration is switched back to default and again to dynamic, the cleanup will be skipped. cc: [~nscendoni] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10486) Resolution of inherited groups may terminate pre-maturely for external users
[ https://issues.apache.org/jira/browse/OAK-10486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10486. Resolution: Fixed > Resolution of inherited groups may terminate pre-maturely for external users > > > Key: OAK-10486 > URL: https://issues.apache.org/jira/browse/OAK-10486 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.60.0 > > > for external users with dynamic membership the resolution of inherited local > groups terminates pre-maturely when multiple external groups are combined > with different local groups. > this only applies to User.memberOf calls, while principal-resolution (such as > performed during login), the associated permission evaluation and looking up > group members and membership for groups is not affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10488) Benchmark results
[ https://issues.apache.org/jira/browse/OAK-10488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774471#comment-17774471 ] Angela Schreiber commented on OAK-10488: h2. Benchmark Results h3. LoginTest with Patch https://issues.apache.org/jira/secure/attachment/13063459/LoginTest_20231010_172626_with_patch.csv h3. LoginTest StatusQuo (without Patch) https://issues.apache.org/jira/secure/attachment/13063458/LoginTest_20231010_173013_without_patch.csv > Benchmark results > - > > Key: OAK-10488 > URL: https://issues.apache.org/jira/browse/OAK-10488 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: auth-external, benchmarks >Reporter: Angela Schreiber >Assignee: Nicola Scendoni >Priority: Major > > [~nscendoni], i am creating a separate subtask to OAK-10451 to have an easy > findable record that you verified your patch and it's effect by running an > oak benchmark. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10488) Benchmark results
[ https://issues.apache.org/jira/browse/OAK-10488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10488. Fix Version/s: 1.60.0 Resolution: Done > Benchmark results > - > > Key: OAK-10488 > URL: https://issues.apache.org/jira/browse/OAK-10488 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: auth-external, benchmarks >Reporter: Angela Schreiber >Assignee: Nicola Scendoni >Priority: Major > Fix For: 1.60.0 > > > [~nscendoni], i am creating a separate subtask to OAK-10451 to have an easy > findable record that you verified your patch and it's effect by running an > oak benchmark. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10488) Benchmark results
Angela Schreiber created OAK-10488: -- Summary: Benchmark results Key: OAK-10488 URL: https://issues.apache.org/jira/browse/OAK-10488 Project: Jackrabbit Oak Issue Type: Sub-task Components: auth-external, benchmarks Reporter: Angela Schreiber Assignee: Nicola Scendoni [~nscendoni], i am creating a separate subtask to OAK-10451 to have an easy findable record that you verified your patch and it's effect by running an oak benchmark. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10471) Implement ConflictHandler for UserPrincipalProvider Cache
[ https://issues.apache.org/jira/browse/OAK-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10471. Fix Version/s: 1.60.0 Resolution: Fixed > Implement ConflictHandler for UserPrincipalProvider Cache > - > > Key: OAK-10471 > URL: https://issues.apache.org/jira/browse/OAK-10471 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > Fix For: 1.60.0 > > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. Conflict can > happens on rep:cache when cache expire and load is high. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10471) Implement ConflictHandler for UserPrincipalProvider Cache
[ https://issues.apache.org/jira/browse/OAK-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10471: --- Summary: Implement ConflictHandler for UserPrincipalProvider Cache (was: Implement ConflictHandler for UserPrincipalProvider) > Implement ConflictHandler for UserPrincipalProvider Cache > - > > Key: OAK-10471 > URL: https://issues.apache.org/jira/browse/OAK-10471 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. Conflict can > happens on rep:cache when cache expire and load is high. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10471) Implement ConflictHandler for UserPrincipalProvider
[ https://issues.apache.org/jira/browse/OAK-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10471: -- Assignee: Nicola Scendoni > Implement ConflictHandler for UserPrincipalProvider > --- > > Key: OAK-10471 > URL: https://issues.apache.org/jira/browse/OAK-10471 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. Conflict can > happens on rep:cache when cache expire and load is high. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10486) Resolution of inherited groups may terminate pre-maturely for external users
[ https://issues.apache.org/jira/browse/OAK-10486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10486: --- Fix Version/s: 1.60.0 > Resolution of inherited groups may terminate pre-maturely for external users > > > Key: OAK-10486 > URL: https://issues.apache.org/jira/browse/OAK-10486 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.60.0 > > > for external users with dynamic membership the resolution of inherited local > groups terminates per-maturely when multiple external groups are combined > with different local groups. > this only applies to User.memberOf calls, while principal-resolution (such as > performed during login), the associated permission evaluation and looking up > group members and membership for groups is not affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10486) Resolution of inherited groups may terminate pre-maturely for external users
[ https://issues.apache.org/jira/browse/OAK-10486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10486: --- Description: for external users with dynamic membership the resolution of inherited local groups terminates per-maturely when multiple external groups are combined with different local groups. this only applies to User.memberOf calls, while principal-resolution (such as performed during login), the associated permission evaluation and looking up group members and membership for groups is not affected. was: for external users with dynamic membership the resolution of inherited local groups terminates per-maturely when multiple external groups are combined with different local groups. this only applies to User.memberOf calls, while principal-resolution (such as performed during login), the associated permission evaluation and looking up group members is not affected. > Resolution of inherited groups may terminate pre-maturely for external users > > > Key: OAK-10486 > URL: https://issues.apache.org/jira/browse/OAK-10486 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > for external users with dynamic membership the resolution of inherited local > groups terminates per-maturely when multiple external groups are combined > with different local groups. > this only applies to User.memberOf calls, while principal-resolution (such as > performed during login), the associated permission evaluation and looking up > group members and membership for groups is not affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10486) Resolution of inherited groups may terminate pre-maturely for external users
[ https://issues.apache.org/jira/browse/OAK-10486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10486: --- Summary: Resolution of inherited groups may terminate pre-maturely for external users (was: Resolution of inherited groups may terminate pre-maturely) > Resolution of inherited groups may terminate pre-maturely for external users > > > Key: OAK-10486 > URL: https://issues.apache.org/jira/browse/OAK-10486 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > for external users with dynamic membership the resolution of inherited local > groups terminates per-maturely when multiple external groups are combined > with different local groups. > this only applies to User.memberOf calls, while principal-resolution (such as > performed during login), the associated permission evaluation and looking up > group members is not affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10486) Resolution of inherited groups may terminate pre-maturely
Angela Schreiber created OAK-10486: -- Summary: Resolution of inherited groups may terminate pre-maturely Key: OAK-10486 URL: https://issues.apache.org/jira/browse/OAK-10486 Project: Jackrabbit Oak Issue Type: Bug Components: auth-external Reporter: Angela Schreiber Assignee: Angela Schreiber for external users with dynamic membership the resolution of inherited local groups terminates per-maturely when multiple external groups are combined with different local groups. this only applies to User.memberOf calls, while principal-resolution (such as performed during login), the associated permission evaluation and looking up group members is not affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9922) segment-tar: parallel compaction
[ https://issues.apache.org/jira/browse/OAK-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17773610#comment-17773610 ] Angela Schreiber commented on OAK-9922: --- > I believe this is undesirable yes. definitely. i would call this a bug :-) > segment-tar: parallel compaction > > > Key: OAK-9922 > URL: https://issues.apache.org/jira/browse/OAK-9922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.58.0 > > > Add ability to parallelize compaction over subtrees with multiple threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10451) UserPrincipalProvider may cause many conflicts when under load
[ https://issues.apache.org/jira/browse/OAK-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10451: --- Component/s: core security > UserPrincipalProvider may cause many conflicts when under load > -- > > Key: OAK-10451 > URL: https://issues.apache.org/jira/browse/OAK-10451 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, security >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. This will result > in thundering herd problem when the system is under load and the expiration > time for the cache is reached. Incoming requests that authenticate > concurrently will all try to refresh the cache and cause conflicts because > each request tries to set a new expiration time that is slightly different > from the others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10451) UserPrincipalProvider may cause many conflicts when under load
[ https://issues.apache.org/jira/browse/OAK-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771830#comment-17771830 ] Angela Schreiber commented on OAK-10451: hi [~nscendoni], thanks for reporting this ticket. since have been working on this i added you to the contributors list and assigned the ticket to you. hope that is ok for you. > UserPrincipalProvider may cause many conflicts when under load > -- > > Key: OAK-10451 > URL: https://issues.apache.org/jira/browse/OAK-10451 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. This will result > in thundering herd problem when the system is under load and the expiration > time for the cache is reached. Incoming requests that authenticate > concurrently will all try to refresh the cache and cause conflicts because > each request tries to set a new expiration time that is slightly different > from the others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10451) UserPrincipalProvider may cause many conflicts when under load
[ https://issues.apache.org/jira/browse/OAK-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10451: -- Assignee: Nicola Scendoni > UserPrincipalProvider may cause many conflicts when under load > -- > > Key: OAK-10451 > URL: https://issues.apache.org/jira/browse/OAK-10451 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. This will result > in thundering herd problem when the system is under load and the expiration > time for the cache is reached. Incoming requests that authenticate > concurrently will all try to refresh the cache and cause conflicts because > each request tries to set a new expiration time that is slightly different > from the others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10466) Prevent anonymous user from being disabled
Angela Schreiber created OAK-10466: -- Summary: Prevent anonymous user from being disabled Key: OAK-10466 URL: https://issues.apache.org/jira/browse/OAK-10466 Project: Jackrabbit Oak Issue Type: Wish Components: core, security Reporter: Angela Schreiber today all users except the admin can be disabled preventing it from login. however, this is not sensible for the anonymous user. if anonymous access should not be possible it is recommended to use the corresponding configuration option that doesn't install the anonymous user in the first place. for full backwards compatibility we should have consider placing this behind a configuration option such that consumers can opt out (and still disable the anonymous) if they really want. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10424) Allow Fast Query Size and Insecure Facets to be selectively enabled with query options for permitted principals
[ https://issues.apache.org/jira/browse/OAK-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771536#comment-17771536 ] Angela Schreiber commented on OAK-10424: [~madamcin], i commented on the PR. expanding the list of built-in privileges/permissions is unfortunately not possible without calling collisions with custom privileges that have been defined for a given repository before (it would not impact newly created repositories). unless i am totally mistaken and my memory lets me down, we would need to tackle this differently. the patch in the current form cannot be merged without causing major regressions (and yes this is the fault of the way how custom privileges are handled/stored). let's discuss how we could do it. after all what you try to achieve is closer to what custom privileges are used for than true built-in privileges as you (as far as i could see) don't enforce them during the permission evaluation. > 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)
[jira] [Comment Edited] (OAK-10424) Allow Fast Query Size and Insecure Facets to be selectively enabled with query options for permitted principals
[ https://issues.apache.org/jira/browse/OAK-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771536#comment-17771536 ] Angela Schreiber edited comment on OAK-10424 at 10/3/23 3:54 PM: - [~madamcin], i commented on the PR. expanding the list of built-in privileges/permissions is unfortunately not possible without causing collisions with custom privileges that have been defined for a given repository before (it would not impact newly created repositories). unless i am totally mistaken and my memory lets me down, we would need to tackle this differently. the patch in the current form cannot be merged without causing major regressions (and yes this is the fault of the way how custom privileges are handled/stored). let's discuss how we could do it. after all what you try to achieve is closer to what custom privileges are used for than true built-in privileges as you (as far as i could see) don't enforce them during the permission evaluation. was (Author: anchela): [~madamcin], i commented on the PR. expanding the list of built-in privileges/permissions is unfortunately not possible without calling collisions with custom privileges that have been defined for a given repository before (it would not impact newly created repositories). unless i am totally mistaken and my memory lets me down, we would need to tackle this differently. the patch in the current form cannot be merged without causing major regressions (and yes this is the fault of the way how custom privileges are handled/stored). let's discuss how we could do it. after all what you try to achieve is closer to what custom privileges are used for than true built-in privileges as you (as far as i could see) don't enforce them during the permission evaluation. > 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
[jira] [Resolved] (OAK-10318) Improve AutoMembershipPrincipals#isInheritedMember
[ https://issues.apache.org/jira/browse/OAK-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10318. Fix Version/s: 1.56.0 Resolution: Fixed > Improve AutoMembershipPrincipals#isInheritedMember > -- > > Key: OAK-10318 > URL: https://issues.apache.org/jira/browse/OAK-10318 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.56.0 > > > the current implementation of AutoMembershipPrincipals#isInheritedMember is > not particularly efficient and could most certainly be improved by starting > from the configured automembership groups and distinguishing between user and > group members. > addressing this should come with a dedicated benchmark test to verify the > improvement. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10364) Consolidate inheritance related automembership tests
[ https://issues.apache.org/jira/browse/OAK-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10364. Fix Version/s: 1.56.0 Resolution: Fixed > Consolidate inheritance related automembership tests > > > Key: OAK-10364 > URL: https://issues.apache.org/jira/browse/OAK-10364 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.56.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10364) Consolidate inheritance related automembership tests
[ https://issues.apache.org/jira/browse/OAK-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10364: -- Assignee: Angela Schreiber > Consolidate inheritance related automembership tests > > > Key: OAK-10364 > URL: https://issues.apache.org/jira/browse/OAK-10364 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10363) Benchmark results
[ https://issues.apache.org/jira/browse/OAK-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10363. Fix Version/s: 1.56.0 Assignee: Angela Schreiber Resolution: Done > Benchmark results > - > > Key: OAK-10363 > URL: https://issues.apache.org/jira/browse/OAK-10363 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.56.0 > > Attachments: default-AutoMembershipTest_20230719_192706.csv, > dynamic-OAK-10318-AutoMembershipTest_20230720_120253.csv, > dynamic-statusquo-AutoMembershipTest_20230719_150353.csv, > run_external_automembership.sh > > > results for benchmarks created with OAK-10362 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10362) Create benchmark test
[ https://issues.apache.org/jira/browse/OAK-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10362: -- Assignee: Angela Schreiber > Create benchmark test > - > > Key: OAK-10362 > URL: https://issues.apache.org/jira/browse/OAK-10362 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.56.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10363) Benchmark results
[ https://issues.apache.org/jira/browse/OAK-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10363: --- Description: results for benchmarks created with OAK-10362 > Benchmark results > - > > Key: OAK-10363 > URL: https://issues.apache.org/jira/browse/OAK-10363 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Priority: Major > Attachments: default-AutoMembershipTest_20230719_192706.csv, > dynamic-OAK-10318-AutoMembershipTest_20230720_120253.csv, > dynamic-statusquo-AutoMembershipTest_20230719_150353.csv, > run_external_automembership.sh > > > results for benchmarks created with OAK-10362 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10363) Benchmark results
[ https://issues.apache.org/jira/browse/OAK-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10363: --- Attachment: run_external_automembership.sh > Benchmark results > - > > Key: OAK-10363 > URL: https://issues.apache.org/jira/browse/OAK-10363 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Priority: Major > Attachments: default-AutoMembershipTest_20230719_192706.csv, > dynamic-OAK-10318-AutoMembershipTest_20230720_120253.csv, > dynamic-statusquo-AutoMembershipTest_20230719_150353.csv, > run_external_automembership.sh > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10363) Benchmark results
[ https://issues.apache.org/jira/browse/OAK-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10363: --- Attachment: default-AutoMembershipTest_20230719_192706.csv > Benchmark results > - > > Key: OAK-10363 > URL: https://issues.apache.org/jira/browse/OAK-10363 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Priority: Major > Attachments: default-AutoMembershipTest_20230719_192706.csv, > dynamic-OAK-10318-AutoMembershipTest_20230720_120253.csv, > dynamic-statusquo-AutoMembershipTest_20230719_150353.csv > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10363) Benchmark results
[ https://issues.apache.org/jira/browse/OAK-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10363: --- Attachment: dynamic-statusquo-AutoMembershipTest_20230719_150353.csv > Benchmark results > - > > Key: OAK-10363 > URL: https://issues.apache.org/jira/browse/OAK-10363 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Priority: Major > Attachments: default-AutoMembershipTest_20230719_192706.csv, > dynamic-OAK-10318-AutoMembershipTest_20230720_120253.csv, > dynamic-statusquo-AutoMembershipTest_20230719_150353.csv > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10363) Benchmark results
[ https://issues.apache.org/jira/browse/OAK-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10363: --- Attachment: dynamic-OAK-10318-AutoMembershipTest_20230720_120253.csv > Benchmark results > - > > Key: OAK-10363 > URL: https://issues.apache.org/jira/browse/OAK-10363 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Priority: Major > Attachments: default-AutoMembershipTest_20230719_192706.csv, > dynamic-OAK-10318-AutoMembershipTest_20230720_120253.csv, > dynamic-statusquo-AutoMembershipTest_20230719_150353.csv > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10362) Create benchmark test
[ https://issues.apache.org/jira/browse/OAK-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10362. Fix Version/s: 1.56.0 Resolution: Fixed > Create benchmark test > - > > Key: OAK-10362 > URL: https://issues.apache.org/jira/browse/OAK-10362 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Angela Schreiber >Priority: Major > Fix For: 1.56.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10364) Consolidate inheritance related automembership tests
Angela Schreiber created OAK-10364: -- Summary: Consolidate inheritance related automembership tests Key: OAK-10364 URL: https://issues.apache.org/jira/browse/OAK-10364 Project: Jackrabbit Oak Issue Type: Sub-task Reporter: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10362) Create benchmark test
Angela Schreiber created OAK-10362: -- Summary: Create benchmark test Key: OAK-10362 URL: https://issues.apache.org/jira/browse/OAK-10362 Project: Jackrabbit Oak Issue Type: Sub-task Reporter: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10363) Benchmark results
Angela Schreiber created OAK-10363: -- Summary: Benchmark results Key: OAK-10363 URL: https://issues.apache.org/jira/browse/OAK-10363 Project: Jackrabbit Oak Issue Type: Sub-task Reporter: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10335) TypeEditor misapplies default primary type of child node to its parent when the child primary type is not set
[
https://issues.apache.org/jira/browse/OAK-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742306#comment-17742306
]
Angela Schreiber commented on OAK-10335:
[~madamcin], you are right that {{TypeEditor}} has most likely issue. However,
any tool operating on the jcr repository should make sure that the content it
creates is meaningful. since this is not the adobe jira you don't have to
provide details about a closed source application, but i would strongly
recommend that the team responsible for this tool, works on it's stability. if
it by-passes JCR API and direct operates on a lower API level, it needs to make
sure that the content written is consistent and correct.
i checked where the {{TypeEditorProvider}} is used in oak with 'strict' mode
being set to false:
- oak-upgrade as 'copy' (Copies the full content from the source to the target
repository.)
- oak-upgrade as RepositorySidegrade for migrateWithoutCheckpoints
both don't seem to be prone to the problem you are describing so it might
be caused by the tool you are mentioning.
i am therefore reducing the priority of this bug.
> TypeEditor misapplies default primary type of child node to its parent when
> the child primary type is not set
> --
>
> Key: OAK-10335
> URL: https://issues.apache.org/jira/browse/OAK-10335
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.52.0
>Reporter: Mark Adamcin
>Priority: Critical
>
> h2. Preconditions
> * Child node's "after" state does not have a jcr:primaryType property
> * TypeEditorProvider is created with strict=false to suppress the
> ConstraintViolationException for the missing jcr:primaryType property
> * Parent node's effective type specifies a default type for the child's node
> name
> h2. Summary
> This issue ultimately presented in an AEM author environment as a Sling
> Repository Initializer exception:
>
> {code:java}
> Exception in a SlingRepositoryInitializer, SlingRepository service
> registration aborted throwable : javax.jcr.RepositoryException: Applying
> repoinit operation failed despite retry; set loglevel to DEBUG to see all
> exceptions. Last exception message was: Session.save failed:
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /conf/rep:policy[[rep:GrantACE]]: No matching definition found for child node
> deny90 with effective type [rep:DenyACE]_ {code}
> somehow the jcr:primaryType values for each segment of the relative path
> under /conf, rep:policy/allow78/rep:restrictions, had been saved to its
> parent. What should have been:
> *rep:policy(rep:ACL)/allow78(rep:GrantACE)/rep:restrictions(rep:Restrictions)*
> had been committed as
> *rep:policy(rep:GrantACE)/allow78(rep:Restrictions)/rep:restrictions( set>)*
> Additionally, the jcr:primaryType properties for rep:policy and allow78 HAD
> been set correctly in previous commit roots, but had been changed incorrectly
> in the same commit that created the rep:restrictions node. The same commit
> had also included changes to a list of linked principal names that could not
> be correlated with any artifact in the custom code or installed filevault
> packages.
>
> After changing the jcr:primaryType properties directly in the mongodb
> database to allow the repository to complete its startup, further
> investigation determined that a Content Transfer Tool import had been
> executed just prior to the first appearance of this error in the server logs.
> The fact that the rep:restrictions node had been persisted without a
> jcr:primaryType property strongly suggested that the corrupting change had
> not been made through the JCR API.
> The other important detail is that the rep:glob property was properly saved
> to the rep:restrictions node as part of the same commit, which implies that
> the jcr:primaryType property is subject to some special treatment in this
> situation.
> These details led me to suspect that the TypeEditor is the source of this
> behavior.
> The TypeEditor normally rejects a commit with a ConstraintViolationException
> when an "after" node state lacks a jcr:primaryType property, but it will
> instead only log this condition if the TypeEditorProvider is created with
> strict=false. I've confirmed that this is how the Content Transfer Tool
> importer constructs its root type editor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10335) TypeEditor misapplies default primary type of child node to its parent when the child primary type is not set
[
https://issues.apache.org/jira/browse/OAK-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10335:
---
Priority: Major (was: Critical)
> TypeEditor misapplies default primary type of child node to its parent when
> the child primary type is not set
> --
>
> Key: OAK-10335
> URL: https://issues.apache.org/jira/browse/OAK-10335
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.52.0
>Reporter: Mark Adamcin
>Priority: Major
>
> h2. Preconditions
> * Child node's "after" state does not have a jcr:primaryType property
> * TypeEditorProvider is created with strict=false to suppress the
> ConstraintViolationException for the missing jcr:primaryType property
> * Parent node's effective type specifies a default type for the child's node
> name
> h2. Summary
> This issue ultimately presented in an AEM author environment as a Sling
> Repository Initializer exception:
>
> {code:java}
> Exception in a SlingRepositoryInitializer, SlingRepository service
> registration aborted throwable : javax.jcr.RepositoryException: Applying
> repoinit operation failed despite retry; set loglevel to DEBUG to see all
> exceptions. Last exception message was: Session.save failed:
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /conf/rep:policy[[rep:GrantACE]]: No matching definition found for child node
> deny90 with effective type [rep:DenyACE]_ {code}
> somehow the jcr:primaryType values for each segment of the relative path
> under /conf, rep:policy/allow78/rep:restrictions, had been saved to its
> parent. What should have been:
> *rep:policy(rep:ACL)/allow78(rep:GrantACE)/rep:restrictions(rep:Restrictions)*
> had been committed as
> *rep:policy(rep:GrantACE)/allow78(rep:Restrictions)/rep:restrictions( set>)*
> Additionally, the jcr:primaryType properties for rep:policy and allow78 HAD
> been set correctly in previous commit roots, but had been changed incorrectly
> in the same commit that created the rep:restrictions node. The same commit
> had also included changes to a list of linked principal names that could not
> be correlated with any artifact in the custom code or installed filevault
> packages.
>
> After changing the jcr:primaryType properties directly in the mongodb
> database to allow the repository to complete its startup, further
> investigation determined that a Content Transfer Tool import had been
> executed just prior to the first appearance of this error in the server logs.
> The fact that the rep:restrictions node had been persisted without a
> jcr:primaryType property strongly suggested that the corrupting change had
> not been made through the JCR API.
> The other important detail is that the rep:glob property was properly saved
> to the rep:restrictions node as part of the same commit, which implies that
> the jcr:primaryType property is subject to some special treatment in this
> situation.
> These details led me to suspect that the TypeEditor is the source of this
> behavior.
> The TypeEditor normally rejects a commit with a ConstraintViolationException
> when an "after" node state lacks a jcr:primaryType property, but it will
> instead only log this condition if the TypeEditorProvider is created with
> strict=false. I've confirmed that this is how the Content Transfer Tool
> importer constructs its root type editor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10317) Additional tests for dynamic automembership
[ https://issues.apache.org/jira/browse/OAK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10317. Fix Version/s: 1.54.0 Resolution: Fixed > Additional tests for dynamic automembership > --- > > Key: OAK-10317 > URL: https://issues.apache.org/jira/browse/OAK-10317 > Project: Jackrabbit Oak > Issue Type: Test > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10318) Improve AutoMembershipPrincipals#isInheritedMember
Angela Schreiber created OAK-10318: -- Summary: Improve AutoMembershipPrincipals#isInheritedMember Key: OAK-10318 URL: https://issues.apache.org/jira/browse/OAK-10318 Project: Jackrabbit Oak Issue Type: Improvement Components: auth-external Reporter: Angela Schreiber Assignee: Angela Schreiber the current implementation of AutoMembershipPrincipals#isInheritedMember is not particularly efficient and could most certainly be improved by starting from the configured automembership groups and distinguishing between user and group members. addressing this should come with a dedicated benchmark test to verify the improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10304) log registration of invalid namespace names
[
https://issues.apache.org/jira/browse/OAK-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735770#comment-17735770
]
Angela Schreiber commented on OAK-10304:
[~reschke] , if i read the PR correctly you omit logging an error for the
internal namespace, right? that would be important as we would otherwise get
errors in the log, we don't really want to see.
> log registration of invalid namespace names
> ---
>
> Key: OAK-10304
> URL: https://issues.apache.org/jira/browse/OAK-10304
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.54.0
>
>
> Example:
> {noformat}
> diff --git
> a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> index f113e4e0d2..7178a36f7f 100644
> --- a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> +++ b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> @@ -1996,6 +1996,24 @@ public class RepositoryTest extends
> AbstractRepositoryTest {
> assertFalse(asList(nsReg.getURIs()).contains("file:///foo"));
> }
> +@Test
> +public void testNamespaceNames() throws RepositoryException {
> +NamespaceRegistry nsReg =
> +getAdminSession().getWorkspace().getNamespaceRegistry();
> +
> +// valid
> +nsReg.registerNamespace("foo", "https://example.com";);
> +nsReg.unregisterNamespace("foo");
> +
> +// invalid
> +try {
> +nsReg.registerNamespace("foo", "example.com");
> +fail("should not register invalid namespace name");
> +} finally {
> +nsReg.unregisterNamespace("foo");
> +}
> +}
> {noformat}
> Note that name of nodes using invalid namespaces do have a valid "expanded
> form" variant
> (https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10317) Additional tests for dynamic automembership
Angela Schreiber created OAK-10317: -- Summary: Additional tests for dynamic automembership Key: OAK-10317 URL: https://issues.apache.org/jira/browse/OAK-10317 Project: Jackrabbit Oak Issue Type: Test Components: auth-external Reporter: Angela Schreiber Assignee: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10304) Oak allows registration of invalid namespace names
[
https://issues.apache.org/jira/browse/OAK-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732927#comment-17732927
]
Angela Schreiber commented on OAK-10304:
[~reschke], i agree that fixing without backwards-compatibility option will
likely cause issues. so, think we have a couple of options:
- document this as a known limitation/bug and resolve this ticket as won't fix,
but log a message when an invalid namespace is registered
- fix the problem with an option to disable it for backwards compatibility, in
which case i would also log a message (see before)
about the log level: i would log it as a warning.
apart from that i don't have a strong preference for either variant but i guess
the first one is easier, no?
> Oak allows registration of invalid namespace names
> --
>
> Key: OAK-10304
> URL: https://issues.apache.org/jira/browse/OAK-10304
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> Example:
> {noformat}
> diff --git
> a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> index f113e4e0d2..7178a36f7f 100644
> --- a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> +++ b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> @@ -1996,6 +1996,24 @@ public class RepositoryTest extends
> AbstractRepositoryTest {
> assertFalse(asList(nsReg.getURIs()).contains("file:///foo"));
> }
> +@Test
> +public void testNamespaceNames() throws RepositoryException {
> +NamespaceRegistry nsReg =
> +getAdminSession().getWorkspace().getNamespaceRegistry();
> +
> +// valid
> +nsReg.registerNamespace("foo", "https://example.com";);
> +nsReg.unregisterNamespace("foo");
> +
> +// invalid
> +try {
> +nsReg.registerNamespace("foo", "example.com");
> +fail("should not register invalid namespace name");
> +} finally {
> +nsReg.unregisterNamespace("foo");
> +}
> +}
> {noformat}
> Note that name of nodes using invalid namespaces do have a valid "expanded
> form" variant
> (https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10286) AutoMembershipPrincipals.isInheritedMember add check for cyclic membership
[
https://issues.apache.org/jira/browse/OAK-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10286.
Fix Version/s: 1.54.0
Resolution: Fixed
> AutoMembershipPrincipals.isInheritedMember add check for cyclic membership
> --
>
> Key: OAK-10286
> URL: https://issues.apache.org/jira/browse/OAK-10286
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.54.0
>
>
> in contrast to {{MembershipProvider}} the
> {{AutoMembershipPrincipals#isInheritedMember}} does not come with a defensive
> check against cyclic membership.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10285) MembershipProvider change log level to ERROR for cyclic membership
[ https://issues.apache.org/jira/browse/OAK-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10285. Fix Version/s: 1.54.0 Resolution: Fixed > MembershipProvider change log level to ERROR for cyclic membership > -- > > Key: OAK-10285 > URL: https://issues.apache.org/jira/browse/OAK-10285 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, security >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.54.0 > > > MembershipProvider.getMembers will log a WARNing if a cyclic membership is > detected. however, these WARNings tend to get overlooked and it would be > better to log an error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10285) MembershipProvider change log level to ERROR for cyclic membership
[ https://issues.apache.org/jira/browse/OAK-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10285: --- Summary: MembershipProvider change log level to ERROR for cyclic membership (was: MembershipProvider: change log level to ERROR for cyclic membership) > MembershipProvider change log level to ERROR for cyclic membership > -- > > Key: OAK-10285 > URL: https://issues.apache.org/jira/browse/OAK-10285 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, security >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > MembershipProvider.getMembers will log a WARNing if a cyclic membership is > detected. however, these WARNings tend to get overlooked and it would be > better to log an error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10286) AutoMembershipPrincipals.isInheritedMember add check for cyclic membership
[
https://issues.apache.org/jira/browse/OAK-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated OAK-10286:
---
Summary: AutoMembershipPrincipals.isInheritedMember add check for cyclic
membership (was: AutoMembershipPrincipals.isInheritedMember : add check for
cyclic membership)
> AutoMembershipPrincipals.isInheritedMember add check for cyclic membership
> --
>
> Key: OAK-10286
> URL: https://issues.apache.org/jira/browse/OAK-10286
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> in contrast to {{MembershipProvider}} the
> {{AutoMembershipPrincipals#isInheritedMember}} does not come with a defensive
> check against cyclic membership.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10286) AutoMembershipPrincipals.isInheritedMember : add check for cyclic membership
[
https://issues.apache.org/jira/browse/OAK-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber reassigned OAK-10286:
--
Assignee: Angela Schreiber
> AutoMembershipPrincipals.isInheritedMember : add check for cyclic membership
>
>
> Key: OAK-10286
> URL: https://issues.apache.org/jira/browse/OAK-10286
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> in contrast to {{MembershipProvider}} the
> {{AutoMembershipPrincipals#isInheritedMember}} does not come with a defensive
> check against cyclic membership.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10286) AutoMembershipPrincipals.isInheritedMember : add check for cyclic membership
Angela Schreiber created OAK-10286:
--
Summary: AutoMembershipPrincipals.isInheritedMember : add check
for cyclic membership
Key: OAK-10286
URL: https://issues.apache.org/jira/browse/OAK-10286
Project: Jackrabbit Oak
Issue Type: Improvement
Components: auth-external
Reporter: Angela Schreiber
in contrast to {{MembershipProvider}} the
{{AutoMembershipPrincipals#isInheritedMember}} does not come with a defensive
check against cyclic membership.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10285) MembershipProvider: change log level to ERROR for cyclic membership
Angela Schreiber created OAK-10285: -- Summary: MembershipProvider: change log level to ERROR for cyclic membership Key: OAK-10285 URL: https://issues.apache.org/jira/browse/OAK-10285 Project: Jackrabbit Oak Issue Type: Improvement Components: core, security Reporter: Angela Schreiber Assignee: Angela Schreiber MembershipProvider.getMembers will log a WARNing if a cyclic membership is detected. however, these WARNings tend to get overlooked and it would be better to log an error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10271) Fix dependencies on oak-exercise
[
https://issues.apache.org/jira/browse/OAK-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10271.
Fix Version/s: 1.54.0
Resolution: Fixed
thanks [~mreutegg] and [~nscendoni]
> Fix dependencies on oak-exercise
>
>
> Key: OAK-10271
> URL: https://issues.apache.org/jira/browse/OAK-10271
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: exercise
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.54.0
>
>
> [~nscendoni] reported that running exercises is broken and [~mreutegg]
> provided a fix for the pom.xml:
> {code}
> diff --git a/oak-exercise/pom.xml b/oak-exercise/pom.xml
> index 3c4dfbc9fe..e3469dff6d 100644
> --- a/oak-exercise/pom.xml
> +++ b/oak-exercise/pom.xml
> @@ -41,7 +41,7 @@
> org.apache.maven.plugins
> maven-surefire-plugin
>
> - true
> + false
>
>
>
> @@ -182,6 +182,13 @@
>${jackrabbit.version}
>true
>
> +
> + org.apache.jackrabbit
> + oak-commons
> + ${project.version}
> + test-jar
> + test
> +
>
>org.apache.jackrabbit
>oak-core
> @@ -208,12 +215,28 @@
>${project.version}
>test
>
> +
> + org.apache.jackrabbit
> + oak-store-document
> + ${project.version}
> + test
> +
>
>org.apache.jackrabbit
>oak-store-composite
>${project.version}
>test
>
> +
> + io.dropwizard.metrics
> + metrics-core
> + test
> +
> +
> + org.mockito
> + mockito-core
> + test
> +
>
>ch.qos.logback
>logback-classic
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10271) Fix dependencies on oak-exercise
Angela Schreiber created OAK-10271:
--
Summary: Fix dependencies on oak-exercise
Key: OAK-10271
URL: https://issues.apache.org/jira/browse/OAK-10271
Project: Jackrabbit Oak
Issue Type: Task
Components: exercise
Reporter: Angela Schreiber
Assignee: Angela Schreiber
[~nscendoni] reported that running exercises is broken and [~mreutegg] provided
a fix for the pom.xml:
{code}
diff --git a/oak-exercise/pom.xml b/oak-exercise/pom.xml
index 3c4dfbc9fe..e3469dff6d 100644
--- a/oak-exercise/pom.xml
+++ b/oak-exercise/pom.xml
@@ -41,7 +41,7 @@
org.apache.maven.plugins
maven-surefire-plugin
- true
+ false
@@ -182,6 +182,13 @@
${jackrabbit.version}
true
+
+ org.apache.jackrabbit
+ oak-commons
+ ${project.version}
+ test-jar
+ test
+
org.apache.jackrabbit
oak-core
@@ -208,12 +215,28 @@
${project.version}
test
+
+ org.apache.jackrabbit
+ oak-store-document
+ ${project.version}
+ test
+
org.apache.jackrabbit
oak-store-composite
${project.version}
test
+
+ io.dropwizard.metrics
+ metrics-core
+ test
+
+
+ org.mockito
+ mockito-core
+ test
+
ch.qos.logback
logback-classic
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10270) Document limitation
[ https://issues.apache.org/jira/browse/OAK-10270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10270. Fix Version/s: 1.54.0 Resolution: Fixed documented limitation on https://jackrabbit.apache.org/oak/docs/security/permission/default.html > Document limitation > --- > > Key: OAK-10270 > URL: https://issues.apache.org/jira/browse/OAK-10270 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: doc >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10270) Document limitation
Angela Schreiber created OAK-10270: -- Summary: Document limitation Key: OAK-10270 URL: https://issues.apache.org/jira/browse/OAK-10270 Project: Jackrabbit Oak Issue Type: Technical task Components: doc Reporter: Angela Schreiber Assignee: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10269) TreePermissionImpl.canRead(PropertyState) doesn't check READ_ACCESS_CONTROL for isolated property
Angela Schreiber created OAK-10269:
--
Summary: TreePermissionImpl.canRead(PropertyState) doesn't check
READ_ACCESS_CONTROL for isolated property
Key: OAK-10269
URL: https://issues.apache.org/jira/browse/OAK-10269
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, security
Reporter: Angela Schreiber
[~rma61...@adobe.com] spotted an issue with
{{TreePermissionImpl.canRead(PropertyState)}} in a customized authorization
setup that defines isolated access control properties that are not located with
a access controlled node.
h3. Setup
- define a custom authorization model that comes with a {{Context}}
implementation marking isolated properties as access control content without
having the parent node be access controlled (i.e. outside of a policy node)
- plug the authorization model into an oak security setup
- grant a test user read access to the tree where the isolated ac-properties
are defined, but don't grant {{jcr:readAccessControl}} privilege
- testing {{Session.hasPermission}} for the isolated properties returns the
expected result
- however, the test session is able to read the property with just regular
read-access granted
- writing the property only works if {{jcr:modifyAccessControl}} privilege is
granted (as expected)
h3. Analysis
{{TreePermissionImpl#canRead(Property)}} [1] verifies if the parent tree is
access controlled and does not check if the property itself is access control
outside of an access controlled tree. In other words: isolated access control
properties that are not below an access controlled tree, will not be found to
be access control content.
All access control properties shipped with Oak are associated with an access
control policy node. The issue therefore only applies to custom models that
- define isolated access control properties
- rely on the the default authorization model to enforce READ_ACCESS_CONTROL
permission
h3. Next steps
The fix for TreePermissionImpl#canRead(Property) itself would be straight
forward, but I have 2 concerns:
- we need to evaluate if that's the only place where the code expects all
access controlled properties to be located below an access controlled node
- additional checking the ac-status of every single property (instead of just
relying on the Tree-type of the parent may impact overall read performance and
extra benchmarks will be needed to assess that.
Unless we have an urgent need to get this fixed, I would therefore suggest to
document the current behavior as know limitation of the default authorization
model.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10260) javadoc generation fails for oak-run due to shaded guava
[
https://issues.apache.org/jira/browse/OAK-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725772#comment-17725772
]
Angela Schreiber commented on OAK-10260:
[~reschke], nor do i. but do we really need to generate javadoc for
oak-run? there are a bunch of modules in oak where building javadoc doesn't
make too much sense (benchmarks, exercises, run, examples, it-osgi, pojosr and
probably more) if excluding them would allow for having the latest javadoc
published, i would do that as a tmp workaround. wdyt?
> javadoc generation fails for oak-run due to shaded guava
>
>
> Key: OAK-10260
> URL: https://issues.apache.org/jira/browse/OAK-10260
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [ERROR] Failed to execute goal
> org.codehaus.gmavenplus:gmavenplus-plugin:1.13.1:compile (default) on project
> oak-run: Error occurred while calling a method on a Groovy class from
> classpath.: InvocationTargetException: startup failed:
> [ERROR] General error during instruction selection:
> java.lang.NoClassDefFoundError:
> org.apache.jackrabbit.guava.common.base.Predicate
> [ERROR]
> [ERROR] java.lang.RuntimeException: java.lang.NoClassDefFoundError:
> org.apache.jackrabbit.guava.common.base.Predicate
> [ERROR] at
> org.codehaus.groovy.control.CompilationUnit.convertUncaughtExceptionToCompilationError(CompilationUnit.java:1089)
> [ERROR] at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1069)
> [ERROR] at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:623)
> [ERROR] at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:602)
> [ERROR] at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:579)
> [ERROR] at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
> [ERROR] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [ERROR] at
> org.codehaus.gmavenplus.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:212)
> [ERROR] at
> org.codehaus.gmavenplus.mojo.AbstractCompileMojo.doCompile(AbstractCompileMojo.java:334)
> [ERROR] at
> org.codehaus.gmavenplus.mojo.CompileMojo.execute(CompileMojo.java:70)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:355)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
> [ERROR] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> java.base/jdk.internal.refl
[jira] [Resolved] (OAK-10256) Principal documentation does not mention GroupPrincipal
[ https://issues.apache.org/jira/browse/OAK-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10256. Fix Version/s: 1.54.0 Resolution: Fixed > Principal documentation does not mention GroupPrincipal > --- > > Key: OAK-10256 > URL: https://issues.apache.org/jira/browse/OAK-10256 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: docs >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.54.0 > > > the documentation at > https://jackrabbit.apache.org/oak/docs/security/principal.html#jackrabbit-api > does not mention the GroupPrincipal interface introduced to replace > java.security.acl.Group -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-8267) Limit number of values in 'nestedCugs' hidden property in NestedCugHook
[
https://issues.apache.org/jira/browse/OAK-8267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725284#comment-17725284
]
Angela Schreiber commented on OAK-8267:
---
[~rma61...@adobe.com], one way to address this would be to change the format of
the hidden property from mv to a single valued string.
> Limit number of values in 'nestedCugs' hidden property in NestedCugHook
> ---
>
> Key: OAK-8267
> URL: https://issues.apache.org/jira/browse/OAK-8267
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: authorization-cug
>Reporter: Tom Blackford
>Priority: Minor
>
> The logic in NestedCugHook.addNestedCugPath maintains a hidden multivalue
> string property at /:nestedCugs (see [1]).
> If a customer had many thousands of CUGs, this would result in many thousands
> of values on this string property which is unlikely to scale.
> From [~anchela]:
> {quote}
> the reason for storing it is performance optimization i.e. minimizing
> reading from nodes to see if they hold a cug if the intended usages is that
> there are few and most nodes don't have a cug. i wouldn't not want to remove
> the hidden property for that default use case. but we could for sure take a
> look to see if we could introduce a threshold similar to the one at the root
> node i.e. using a counter instead of maintaining the complete list and in
> addition drop the list altogether in that case
> {quote}
> [1]
> https://github.com/apache/jackrabbit-oak/blob/073f2b5378cd198a9cb30eb1f57958fb805ce508/oak-authorization-cug/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/cug/impl/NestedCugHook.java#L79
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (OAK-10256) Principal documentation does not mention GroupPrincipal
[ https://issues.apache.org/jira/browse/OAK-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber moved JCR-4934 to OAK-10256: - Component/s: docs (was: docs) Key: OAK-10256 (was: JCR-4934) Workflow: no-reopen-closed (was: no-reopen-closed, patch-avail) Project: Jackrabbit Oak (was: Jackrabbit Content Repository) > Principal documentation does not mention GroupPrincipal > --- > > Key: OAK-10256 > URL: https://issues.apache.org/jira/browse/OAK-10256 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: docs >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > > the documentation at > https://jackrabbit.apache.org/oak/docs/security/principal.html#jackrabbit-api > does not mention the GroupPrincipal interface introduced to replace > java.security.acl.Group -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10245) Document OAK-10173
[ https://issues.apache.org/jira/browse/OAK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10245: --- Component/s: doc security > Document OAK-10173 > -- > > Key: OAK-10245 > URL: https://issues.apache.org/jira/browse/OAK-10245 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: doc, security >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10173) Allow configured principals to impersonate any user
[ https://issues.apache.org/jira/browse/OAK-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10173. Fix Version/s: 1.54.0 Resolution: Fixed [~antoniu98], thanks a lot for this contribution and the effort you put into this. very much appreciated. > Allow configured principals to impersonate any user > --- > > Key: OAK-10173 > URL: https://issues.apache.org/jira/browse/OAK-10173 > Project: Jackrabbit Oak > Issue Type: Story > Components: core, security-spi >Reporter: Antoniu N >Assignee: Antoniu N >Priority: Major > Fix For: 1.54.0 > > > The issue is related to AEM's > [SITES-10289|https://jira.corp.adobe.com/browse/SITES-10289] > Customer Use-case : > Customer is an AMS customer so admin user is not constantly available. > Customer can attempt to contact lock owner, however, they are not available > as well. > User will lock pages when they are working on it and may forget to unlock the > page. > Team will no longer be able to work on the locked page until AMS admin is > available or lock owner admin is available to unlock the page. > Customers have administrators available but administrators do not have the > ability to unlock the pages. > Steps to replicate : > Impersonation: > Create test-author user and add them to content-authors group > Create test-admin user and add them to administrators group > Log into the AEM instance as test-admin and try to impersonate test-author - > this is not possible unless you are logged in as the actual "admin" user. > Current/Experienced Behavior : > Administrators are not able to unlock pages or impersonate users (unless > their user id is added to the impersonators of the target user) > Improved/Expected Behavior : > Administrators should be able to unlock pages and impersonate other users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10245) Document OAK-10173
[ https://issues.apache.org/jira/browse/OAK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10245. Fix Version/s: 1.54.0 Resolution: Done > Document OAK-10173 > -- > > Key: OAK-10245 > URL: https://issues.apache.org/jira/browse/OAK-10245 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10246) Minor cleanup of unused imports, indention and whitespace
[ https://issues.apache.org/jira/browse/OAK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723157#comment-17723157 ] Angela Schreiber commented on OAK-10246: also found some uncovered statements in utils and added a few more tests and improved the javadoc a bit. > Minor cleanup of unused imports, indention and whitespace > - > > Key: OAK-10246 > URL: https://issues.apache.org/jira/browse/OAK-10246 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core, security >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.54.0 > > > [~antoniu98], i merged your PR and will use this subtask to fix some minor > things i spotted during the last review round: unused import statements, > inconsistent indention and few white space issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10246) Minor cleanup of unused imports, indention and whitespace
[ https://issues.apache.org/jira/browse/OAK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10246. Fix Version/s: 1.54.0 Resolution: Done > Minor cleanup of unused imports, indention and whitespace > - > > Key: OAK-10246 > URL: https://issues.apache.org/jira/browse/OAK-10246 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core, security >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.54.0 > > > [~antoniu98], i merged your PR and will use this subtask to fix some minor > things i spotted during the last review round: unused import statements, > inconsistent indention and few white space issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10246) Minor cleanup of unused imports, indention and whitespace
Angela Schreiber created OAK-10246: -- Summary: Minor cleanup of unused imports, indention and whitespace Key: OAK-10246 URL: https://issues.apache.org/jira/browse/OAK-10246 Project: Jackrabbit Oak Issue Type: Technical task Components: core, security Reporter: Angela Schreiber Assignee: Angela Schreiber [~antoniu98], i merged your PR and will use this subtask to fix some minor things i spotted during the last review round: unused import statements, inconsistent indention and few white space issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10245) Document OAK-10173
Angela Schreiber created OAK-10245: -- Summary: Document OAK-10173 Key: OAK-10245 URL: https://issues.apache.org/jira/browse/OAK-10245 Project: Jackrabbit Oak Issue Type: Technical task Reporter: Angela Schreiber Assignee: Angela Schreiber -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10173) Allow configured principals to impersonate any user
[ https://issues.apache.org/jira/browse/OAK-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-10173: -- Assignee: Antoniu N > Allow configured principals to impersonate any user > --- > > Key: OAK-10173 > URL: https://issues.apache.org/jira/browse/OAK-10173 > Project: Jackrabbit Oak > Issue Type: Story > Components: core, security-spi >Reporter: Antoniu N >Assignee: Antoniu N >Priority: Major > > The issue is related to AEM's > [SITES-10289|https://jira.corp.adobe.com/browse/SITES-10289] > Customer Use-case : > Customer is an AMS customer so admin user is not constantly available. > Customer can attempt to contact lock owner, however, they are not available > as well. > User will lock pages when they are working on it and may forget to unlock the > page. > Team will no longer be able to work on the locked page until AMS admin is > available or lock owner admin is available to unlock the page. > Customers have administrators available but administrators do not have the > ability to unlock the pages. > Steps to replicate : > Impersonation: > Create test-author user and add them to content-authors group > Create test-admin user and add them to administrators group > Log into the AEM instance as test-admin and try to impersonate test-author - > this is not possible unless you are logged in as the actual "admin" user. > Current/Experienced Behavior : > Administrators are not able to unlock pages or impersonate users (unless > their user id is added to the impersonators of the target user) > Improved/Expected Behavior : > Administrators should be able to unlock pages and impersonate other users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10173) Allow configured principals to impersonate any user
[ https://issues.apache.org/jira/browse/OAK-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10173: --- Summary: Allow configured principals to impersonate any user (was: Allow members of configured principals to impersonate any user) > Allow configured principals to impersonate any user > --- > > Key: OAK-10173 > URL: https://issues.apache.org/jira/browse/OAK-10173 > Project: Jackrabbit Oak > Issue Type: Story > Components: core, security-spi >Reporter: Antoniu N >Priority: Major > > The issue is related to AEM's > [SITES-10289|https://jira.corp.adobe.com/browse/SITES-10289] > Customer Use-case : > Customer is an AMS customer so admin user is not constantly available. > Customer can attempt to contact lock owner, however, they are not available > as well. > User will lock pages when they are working on it and may forget to unlock the > page. > Team will no longer be able to work on the locked page until AMS admin is > available or lock owner admin is available to unlock the page. > Customers have administrators available but administrators do not have the > ability to unlock the pages. > Steps to replicate : > Impersonation: > Create test-author user and add them to content-authors group > Create test-admin user and add them to administrators group > Log into the AEM instance as test-admin and try to impersonate test-author - > this is not possible unless you are logged in as the actual "admin" user. > Current/Experienced Behavior : > Administrators are not able to unlock pages or impersonate users (unless > their user id is added to the impersonators of the target user) > Improved/Expected Behavior : > Administrators should be able to unlock pages and impersonate other users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10173) Allow members of configured principals to impersonate any user
[ https://issues.apache.org/jira/browse/OAK-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10173: --- Summary: Allow members of configured principals to impersonate any user (was: Allow members of configured groups to impersonate any user) > Allow members of configured principals to impersonate any user > -- > > Key: OAK-10173 > URL: https://issues.apache.org/jira/browse/OAK-10173 > Project: Jackrabbit Oak > Issue Type: Story > Components: core, security-spi >Reporter: Antoniu N >Priority: Major > > The issue is related to AEM's > [SITES-10289|https://jira.corp.adobe.com/browse/SITES-10289] > Customer Use-case : > Customer is an AMS customer so admin user is not constantly available. > Customer can attempt to contact lock owner, however, they are not available > as well. > User will lock pages when they are working on it and may forget to unlock the > page. > Team will no longer be able to work on the locked page until AMS admin is > available or lock owner admin is available to unlock the page. > Customers have administrators available but administrators do not have the > ability to unlock the pages. > Steps to replicate : > Impersonation: > Create test-author user and add them to content-authors group > Create test-admin user and add them to administrators group > Log into the AEM instance as test-admin and try to impersonate test-author - > this is not possible unless you are logged in as the actual "admin" user. > Current/Experienced Behavior : > Administrators are not able to unlock pages or impersonate users (unless > their user id is added to the impersonators of the target user) > Improved/Expected Behavior : > Administrators should be able to unlock pages and impersonate other users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10228) Explain effect of policies for unknown principals and non-existing paths
Angela Schreiber created OAK-10228: -- Summary: Explain effect of policies for unknown principals and non-existing paths Key: OAK-10228 URL: https://issues.apache.org/jira/browse/OAK-10228 Project: Jackrabbit Oak Issue Type: Documentation Components: doc, security Reporter: Angela Schreiber see https://markmail.org/message/ptm44eikguudorh7?q=oak-dev+list:org%2Eapache%2Ejackrabbit%2Eoak-dev+from:%22Konrad+Windszus%22+order:date-backward&page=1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10217) Build Jackrabbit/jackrabbit-oak-trunk #919 failed
[ https://issues.apache.org/jira/browse/OAK-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718906#comment-17718906 ] Angela Schreiber commented on OAK-10217: failing test: org.apache.jackrabbit.oak.segment.spi.persistence.split.SplitPersistenceBlobTest.collectReferences doesn't seem to be related to my latest changes. [~adulceanu], [~miroslav] FYI > Build Jackrabbit/jackrabbit-oak-trunk #919 failed > - > > Key: OAK-10217 > URL: https://issues.apache.org/jira/browse/OAK-10217 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #919 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #919|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/919/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/919/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10224) org.apache.jackrabbit.api.security.user.QueryBuilder.impersonates is not aligned with Impersonation.allows
Angela Schreiber created OAK-10224:
--
Summary:
org.apache.jackrabbit.api.security.user.QueryBuilder.impersonates is not
aligned with Impersonation.allows
Key: OAK-10224
URL: https://issues.apache.org/jira/browse/OAK-10224
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jackrabbit-api
Reporter: Angela Schreiber
while discussing the improvements suggested by [~antoniu98] in OAK-10173 we
found that the API definition of
{{org.apache.jackrabbit.api.security.user.QueryBuilder.impersonates(String
name)}} is not really aligned with {{Impersonation.allows(Subject)}}.
while for the current implementation this doesn't matter as only the admin user
is able to impersonate everyone irrespective of the information stored in
rep:impersonators properties, we can only make a best-effort guess on whether
the specified principal name might result upon login in a subject that contains
any of the configure impersonators principals.
ultimately, i would be desirable if there was a way to pass a subject to
{{org.apache.jackrabbit.api.security.user.QueryBuilder.impersonates}} (or
something equivalent) in order to make it properly aligned with
{{Impersonation.allows(Subject)}}.
note that expanding the API would also require adjusting
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/ja[…]ackrabbit/commons/jackrabbit/user/AuthorizableQueryManager.java.
cc: [~antoniu98] FYI
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10223) Introduce constant for the 'do-create-token' marker value
[ https://issues.apache.org/jira/browse/OAK-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10223. Fix Version/s: 1.52.0 Resolution: Fixed > Introduce constant for the 'do-create-token' marker value > - > > Key: OAK-10223 > URL: https://issues.apache.org/jira/browse/OAK-10223 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, security-spi >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Trivial > Fix For: 1.52.0 > > > today the tokenprovider implementation treats an empty token-attribute as > marker to force the creation of a new token. > the tokenconstants should provide a constant for this and it should be used > consistently across tests in the oak module and in the tokenprovider impl. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10223) Introduce constant for the 'do-create-token' marker value
Angela Schreiber created OAK-10223: -- Summary: Introduce constant for the 'do-create-token' marker value Key: OAK-10223 URL: https://issues.apache.org/jira/browse/OAK-10223 Project: Jackrabbit Oak Issue Type: Improvement Components: core, security-spi Reporter: Angela Schreiber Assignee: Angela Schreiber today the tokenprovider implementation treats an empty token-attribute as marker to force the creation of a new token. the tokenconstants should provide a constant for this and it should be used consistently across tests in the oak module and in the tokenprovider impl. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10173) Allow members of configured groups to impersonate any user
[ https://issues.apache.org/jira/browse/OAK-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718597#comment-17718597 ] Angela Schreiber commented on OAK-10173: [~antoniu98], i slightly adjusted the summary as IMHO this should be a configuration option and not hard-coded. in particular since there exists no 'administrators' group in an ootb Oak. > Allow members of configured groups to impersonate any user > -- > > Key: OAK-10173 > URL: https://issues.apache.org/jira/browse/OAK-10173 > Project: Jackrabbit Oak > Issue Type: Story > Components: core, security-spi >Reporter: Antoniu N >Priority: Major > > The issue is related to AEM's > [SITES-10289|https://jira.corp.adobe.com/browse/SITES-10289] > Customer Use-case : > Customer is an AMS customer so admin user is not constantly available. > Customer can attempt to contact lock owner, however, they are not available > as well. > User will lock pages when they are working on it and may forget to unlock the > page. > Team will no longer be able to work on the locked page until AMS admin is > available or lock owner admin is available to unlock the page. > Customers have administrators available but administrators do not have the > ability to unlock the pages. > Steps to replicate : > Impersonation: > Create test-author user and add them to content-authors group > Create test-admin user and add them to administrators group > Log into the AEM instance as test-admin and try to impersonate test-author - > this is not possible unless you are logged in as the actual "admin" user. > Current/Experienced Behavior : > Administrators are not able to unlock pages or impersonate users (unless > their user id is added to the impersonators of the target user) > Improved/Expected Behavior : > Administrators should be able to unlock pages and impersonate other users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
