[
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353032#comment-14353032
]
Carsten Ziegeler commented on SLING-4461:
-----------------------------------------
The problem is a missmatch between the reference and the call to the API:
ServiceUserMapper#getServiceUserID(bundle, "foo") might return something while
there is no service registered for a mapping with subServiceName="foo"
That sounds wrong.
This *can* be solved by specifying the longer target filter as shown above. I'm
fine with doing so
However, there is still the global fallback - which if configured always
returns something from ServiceUserMapper#getServiceUserID(bundle, "foo") even
if there is no mapping for that bundle! However rethinking this, this would
probably match the !(subServiceName=*) part.
So we could keep the fallbacks in place.
However, we have a problem with dynamics: imagine a running system with a
mapping defined for a bundle, then you want to specify a more fine grained
mapping for the (bundle, sub service name) tuple. Creating the configs is easy,
however the new configuration is not picked up. But that's a different issue.
I'm not in favour of yet adding another proprietary annotation as I hope that
we can move to the official DS annotations soon.
> 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)
