[
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346604#comment-14346604
]
Marius Petria commented on SLING-4461:
--------------------------------------
That is true, in fact a global fallback (a default user for
ServiceUserMapperImpl) cannot be targeted even with such a complex rule.
To summarize the issue in w.r.t SLING-4312: we do not have an equivalence
between service user resolution (ServiceUserMapper. getServiceUserID) and
ServiceUserMapping services. We only have it one way, if there exists a mapping
then the resolution will succeed. That alone will solve a lot of scenarios but
somehow the abstraction barriers are violated: the "developer" requires the
"administrator" to configure the users in a certain way, i.e. via a dedicated
subService.
> Remove fallbacks for service users resolution
> ---------------------------------------------
>
> Key: SLING-4461
> URL: https://issues.apache.org/jira/browse/SLING-4461
> Project: Sling
> Issue Type: Improvement
> Components: Service User Mapper
> Reporter: Marius Petria
> Fix For: Service User Mapper 1.1.2
>
>
> ServiceUserMapperImpl has several levels of fallback for service user
> resolution (fallback to bundle default, or to global default). While this
> offers a lot of flexibility, it introduces non-determinism in a security
> feature. If defaults are set, it can happen (especially at startup) that code
> is executed using different serviceUsers, e.g. a component can execute using
> the bundle default or global default until its specific subService is
> available, and it can be easily imagined how this can cause subtle errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
