[
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)
