[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15653438#comment-15653438 ] Carsten Ziegeler edited comment on SLING-5135 at 11/10/16 8:37 AM: --- [~jsedding] Thanks for taking this up, it looks good to me, especially removing the dependency to jcr.base from jcr.resource is a very good thing was (Author: cziegeler): [~jsedding] Thanks for taking this up, it looks good to me, especially the dependency to jcr.base from jcr.resource is a very good thing > Whitelist legit usages of loginAdministrative and administrative > ResourceResolver > - > > Key: SLING-5135 > URL: https://issues.apache.org/jira/browse/SLING-5135 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso >Assignee: Bertrand Delacretaz > Fix For: JCR Base 2.4.2 > > Attachments: SLING-5135.patch, SLING-5135.patch > > > {{AbstractSlingRepositoryManager}} contains a method that disable > loginAdministrative support > {code} > /** > * Returns whether to disable the > * {@code SlingRepository.loginAdministrative} method or not. > * > * @return {@code true} if {@code SlingRepository.loginAdministrative} is > * disabled. > */ > public final boolean isDisableLoginAdministrative() > {code} > This is a global configuration. It would be nice to have an extension of such > mechanism that contains a white list of (few) legit usage of > {{loginAdministrative}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15652007#comment-15652007 ] Julian Sedding edited comment on SLING-5135 at 11/10/16 8:19 AM: - I think the {{DefaultWhitelist}} can be reduced to the following: {code} "org.apache.sling.discovery.commons", "org.apache.sling.discovery.base", "org.apache.sling.discovery.oak", "org.apache.sling.extensions.webconsolesecurityprovider", "org.apache.sling.i18n", "org.apache.sling.installer.provider.jcr", "org.apache.sling.jcr.base", "org.apache.sling.jcr.contentloader", "org.apache.sling.jcr.davex", "org.apache.sling.jcr.jackrabbit.usermanager", "org.apache.sling.jcr.oak.server", "org.apache.sling.jcr.repoinit", "org.apache.sling.jcr.resource", "org.apache.sling.jcr.webconsole", "org.apache.sling.resourceresolver", "org.apache.sling.servlets.post", // remove when 2.3.16 is released "org.apache.sling.servlets.resolver" {code} I'll run a full build to confirm that this works. was (Author: jsedding): I think the {{DefaultWhitelist}} can be reduced to the following: {code} "org.apache.sling.extensions.webconsolesecurityprovider", "org.apache.sling.installer.provider.jcr", "org.apache.sling.jcr.base", "org.apache.sling.jcr.contentloader", "org.apache.sling.jcr.davex", "org.apache.sling.jcr.jackrabbit.usermanager", "org.apache.sling.jcr.oak.server", "org.apache.sling.jcr.repoinit", "org.apache.sling.jcr.resource", "org.apache.sling.jcr.webconsole", "org.apache.sling.servlets.post" {code} I'll run a full build to confirm that this works. > Whitelist legit usages of loginAdministrative and administrative > ResourceResolver > - > > Key: SLING-5135 > URL: https://issues.apache.org/jira/browse/SLING-5135 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso >Assignee: Bertrand Delacretaz > Fix For: JCR Base 2.4.2 > > Attachments: SLING-5135.patch, SLING-5135.patch > > > {{AbstractSlingRepositoryManager}} contains a method that disable > loginAdministrative support > {code} > /** > * Returns whether to disable the > * {@code SlingRepository.loginAdministrative} method or not. > * > * @return {@code true} if {@code SlingRepository.loginAdministrative} is > * disabled. > */ > public final boolean isDisableLoginAdministrative() > {code} > This is a global configuration. It would be nice to have an extension of such > mechanism that contains a white list of (few) legit usage of > {{loginAdministrative}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15651212#comment-15651212 ] Julian Sedding edited comment on SLING-5135 at 11/9/16 8:43 PM: We should also check whether the default whitelist is still correct, currently it is {code} "org.apache.sling.discovery.commons", "org.apache.sling.discovery.base", "org.apache.sling.discovery.oak", "org.apache.sling.extensions.webconsolesecurityprovider", "org.apache.sling.i18n", "org.apache.sling.installer.provider.jcr", "org.apache.sling.jcr.base", "org.apache.sling.jcr.contentloader", "org.apache.sling.jcr.davex", "org.apache.sling.jcr.jackrabbit.usermanager", "org.apache.sling.jcr.oak.server", "org.apache.sling.jcr.resource", "org.apache.sling.jcr.webconsole", "org.apache.sling.jcr.webdav", "org.apache.sling.junit.core", "org.apache.sling.resourceresolver", "org.apache.sling.scripting.core", "org.apache.sling.scripting.sightly", "org.apache.sling.servlets.post", "org.apache.sling.servlets.resolver", "org.apache.sling.xss" {code} I think some of the above modules don't use login admin anymore was (Author: cziegeler): We should also check whether the default whitelist is still correct, currently it is {source} "org.apache.sling.discovery.commons", "org.apache.sling.discovery.base", "org.apache.sling.discovery.oak", "org.apache.sling.extensions.webconsolesecurityprovider", "org.apache.sling.i18n", "org.apache.sling.installer.provider.jcr", "org.apache.sling.jcr.base", "org.apache.sling.jcr.contentloader", "org.apache.sling.jcr.davex", "org.apache.sling.jcr.jackrabbit.usermanager", "org.apache.sling.jcr.oak.server", "org.apache.sling.jcr.resource", "org.apache.sling.jcr.webconsole", "org.apache.sling.jcr.webdav", "org.apache.sling.junit.core", "org.apache.sling.resourceresolver", "org.apache.sling.scripting.core", "org.apache.sling.scripting.sightly", "org.apache.sling.servlets.post", "org.apache.sling.servlets.resolver", "org.apache.sling.xss" {source} I think some of the above modules don't use login admin anymore > Whitelist legit usages of loginAdministrative and administrative > ResourceResolver > - > > Key: SLING-5135 > URL: https://issues.apache.org/jira/browse/SLING-5135 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso >Assignee: Bertrand Delacretaz > Fix For: JCR Base 2.4.2 > > Attachments: SLING-5135.patch, SLING-5135.patch > > > {{AbstractSlingRepositoryManager}} contains a method that disable > loginAdministrative support > {code} > /** > * Returns whether to disable the > * {@code SlingRepository.loginAdministrative} method or not. > * > * @return {@code true} if {@code SlingRepository.loginAdministrative} is > * disabled. > */ > public final boolean isDisableLoginAdministrative() > {code} > This is a global configuration. It would be nice to have an extension of such > mechanism that contains a white list of (few) legit usage of > {{loginAdministrative}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15604510#comment-15604510 ] Oliver Lietz edited comment on SLING-5135 at 10/25/16 9:01 AM: --- [~bdelacretaz]: can we align the property names making them consistent? Maybe just {{whitelist.bypass}} {{whitelist.bundles.regex}} {{whitelist.bundles.default}} {{whitelist.bundles.additional}} as all lists use BSNs anyway. edit: {{bundles}} added to distinguish from {{bypass}} was (Author: olli): [~bdelacretaz]: can we align the property names making them consistent? Maybe just {{whitelist.regex}} {{whitelist.default}} {{whitelist.additional}} as all lists use BSNs anyway. > Whitelist legit usages of loginAdministrative and administrative > ResourceResolver > - > > Key: SLING-5135 > URL: https://issues.apache.org/jira/browse/SLING-5135 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso >Assignee: Bertrand Delacretaz > Attachments: SLING-5135.patch, SLING-5135.patch > > > {{AbstractSlingRepositoryManager}} contains a method that disable > loginAdministrative support > {code} > /** > * Returns whether to disable the > * {@code SlingRepository.loginAdministrative} method or not. > * > * @return {@code true} if {@code SlingRepository.loginAdministrative} is > * disabled. > */ > public final boolean isDisableLoginAdministrative() > {code} > This is a global configuration. It would be nice to have an extension of such > mechanism that contains a white list of (few) legit usage of > {{loginAdministrative}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15470056#comment-15470056 ] Bertrand Delacretaz edited comment on SLING-5135 at 9/7/16 8:56 AM: bq. ...I suppose calls to ResourceResolverFactory.getAdministrativeResourceResolver ultimately end up in a call to loginAdministrative which is subject to the whitelist? The whitelist is indeed called but with the wrong client bundle reference. Calls to {{getAdministrativeResourceResolver()}} end up calling {{repository.loginAdministrative(null)}} in {{JcrProviderStateFactory}} which uses a {{SlingRepository}} service acquired by the {{JcrResourceProvider}} service. The reference client bundle for the whitelist is then the {{o.a.s.jcr.resource}} bundle even if it's another bundle which called {{getAdministrativeResourceResolver()}}, hiding the actual client bundle from the whitelist. To fix this and take the whitelist into account for {{getAdministrativeResourceResolver()}} calls which end up hitting the {{JcrResourceProvider}} we need to modify that service so that it's registered with a custom {{ServiceFactory}} which stores a reference to the client bundle that's using the {{JcrResourceProvider}} service, as is done in {{AbstractSlingRepositoryManager.registerService()}}. That client bundle reference can then be passed to {{JcrProviderStateFactory}} so that the {{LoginAdminWhitelist}} can be used there, evaluated against the correct client bundle. That's a somewhat complicated explanation - as I said I probably won't have time to work on this right now, so saving this knowledge for later ;-) was (Author: bdelacretaz): bq. ...I suppose calls to ResourceResolverFactory.getAdministrativeResourceResolver ultimately end up in a call to loginAdministrative which is subject to the whitelist? That's not the case - calls to {{getAdministrativeResourceResolver()}} end up calling {{repository.loginAdministrative(null)}} in {{JcrProviderStateFactory}} which uses a {{SlingRepository}} service acquired by the {{JcrResourceProvider}} service. The reference client bundle for the whitelist is then the {{o.a.s.jcr.resource}} bundle even if it's another bundle which called {{getAdministrativeResourceResolver()}}, hiding the actual client bundle from the whitelist. To fix this and take the whitelist into account for {{getAdministrativeResourceResolver()}} calls which end up hitting the {{JcrResourceProvider}} we need to modify that service so that it's registered with a custom {{ServiceFactory}} which stores a reference to the client bundle that's using the {{JcrResourceProvider}} service, as is done in {{AbstractSlingRepositoryManager.registerService()}}. That client bundle reference can then be passed to {{JcrProviderStateFactory}} so that the {{LoginAdminWhitelist}} can be used there, evaluated against the correct client bundle. That's a somewhat complicated explanation - as I said I probably won't have time to work on this right now, so saving this knowledge for later ;-) > Whitelist legit usages of loginAdministrative and administrative > ResourceResolver > - > > Key: SLING-5135 > URL: https://issues.apache.org/jira/browse/SLING-5135 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso >Assignee: Bertrand Delacretaz > Attachments: SLING-5135.patch, SLING-5135.patch > > > {{AbstractSlingRepositoryManager}} contains a method that disable > loginAdministrative support > {code} > /** > * Returns whether to disable the > * {@code SlingRepository.loginAdministrative} method or not. > * > * @return {@code true} if {@code SlingRepository.loginAdministrative} is > * disabled. > */ > public final boolean isDisableLoginAdministrative() > {code} > This is a global configuration. It would be nice to have an extension of such > mechanism that contains a white list of (few) legit usage of > {{loginAdministrative}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466512#comment-15466512 ] Antonio Sanso edited comment on SLING-5135 at 9/6/16 5:53 AM: -- [~bdelacretaz] LGTM. One little thing. I suspect that if we enable this as is it might break some stuff. E.g. {{org.apache.sling.resourceresolver}} has {{loginAdministrative}} calls but is not on the white list. Do we want an extra boolean config thats says {{enableWhiteList}} or is over killing ? On the other point is : do we want to have the same mechanism be applied for administrative ResourceResolver? was (Author: asanso): [~bdelacretaz] LGTM. One little thing. I suspect that if we enable this as is it might break some stuff. E.g. {{org.apache.sling.resourceresolver}} has {{loginAdministrative}} calls but is not on the white list. Do we want an extra boolean config thats says {{enableWhiteList}} or is over killing ? > Whitelist legit usages of loginAdministrative and administrative > ResourceResolver > - > > Key: SLING-5135 > URL: https://issues.apache.org/jira/browse/SLING-5135 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso >Assignee: Bertrand Delacretaz > Attachments: SLING-5135.patch, SLING-5135.patch > > > {{AbstractSlingRepositoryManager}} contains a method that disable > loginAdministrative support > {code} > /** > * Returns whether to disable the > * {@code SlingRepository.loginAdministrative} method or not. > * > * @return {@code true} if {@code SlingRepository.loginAdministrative} is > * disabled. > */ > public final boolean isDisableLoginAdministrative() > {code} > This is a global configuration. It would be nice to have an extension of such > mechanism that contains a white list of (few) legit usage of > {{loginAdministrative}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073669#comment-15073669 ] Bertrand Delacretaz edited comment on SLING-5135 at 1/25/16 5:19 PM: - Note that we'll need a similar mechanism for {{ResourceResolverFactory.getAdministrativeResourceResolver()}}. I have suggested a mechanism on the Sling dev list in the _How to whitelist legit usages of loginAdministrative?_ thread ( http://sling.markmail.org/thread/oszfbjkswnctkynv ) was (Author: bdelacretaz): Note that we'll need a similar mechanism for {{ResourceResolverFactory.getAdministrativeResourceResolver()}}. I have suggested a mechanism on the Sling dev list in the _How to whitelist legit usages of loginAdministrative?_ thread. > Whitelist legit usages of loginAdministrative and administrative > ResourceResolver > - > > Key: SLING-5135 > URL: https://issues.apache.org/jira/browse/SLING-5135 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso >Assignee: Bertrand Delacretaz > > {{AbstractSlingRepositoryManager}} contains a method that disable > loginAdministrative support > {code} > /** > * Returns whether to disable the > * {@code SlingRepository.loginAdministrative} method or not. > * > * @return {@code true} if {@code SlingRepository.loginAdministrative} is > * disabled. > */ > public final boolean isDisableLoginAdministrative() > {code} > This is a global configuration. It would be nice to have an extension of such > mechanism that contains a white list of (few) legit usage of > {{loginAdministrative}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver
[ https://issues.apache.org/jira/browse/SLING-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085551#comment-15085551 ] Bertrand Delacretaz edited comment on SLING-5135 at 1/6/16 3:14 PM: The emerging idea from the dev list thread is to use a whitelist of bundle symbolic names, to indicate which bundles are still allowed to use loginAdmin once that's disabled. Once that's clarified, we might remove or at least clarify the deprecation notice on the SlingRepository.loginAdministrative method, and corresponding ResourceResolver methods. was (Author: bdelacretaz): The emerging idea from the dev list thread is to use a whitelist of bundle symbolic names, to indicate which bundles are still allowed to use loginAdmin once that's disabled. > Whitelist legit usages of loginAdministrative and administrative > ResourceResolver > - > > Key: SLING-5135 > URL: https://issues.apache.org/jira/browse/SLING-5135 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso >Assignee: Bertrand Delacretaz > > {{AbstractSlingRepositoryManager}} contains a method that disable > loginAdministrative support > {code} > /** > * Returns whether to disable the > * {@code SlingRepository.loginAdministrative} method or not. > * > * @return {@code true} if {@code SlingRepository.loginAdministrative} is > * disabled. > */ > public final boolean isDisableLoginAdministrative() > {code} > This is a global configuration. It would be nice to have an extension of such > mechanism that contains a white list of (few) legit usage of > {{loginAdministrative}} -- This message was sent by Atlassian JIRA (v6.3.4#6332)