[
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363013#comment-14363013
]
Felix Meschberger commented on SLING-4461:
------------------------------------------
Service User Mapping has been introduced as a security feature to allow
(background) services to operate in a least privileges required way instead of
granting them all full repository access through
getAdministrativeResourceResolver and loginAdministrative.
The defaults have been introduced as a convenience measure allowing to migrate
code towards service user mapping.
Now the the ServiceUserMapping service introduced with SLING-4312 "enforces" a
stricter approach. From a security point of view, this is actually better,
since this makes sure a component is only enabled if the expected service user
mapping is actually exactly given as required.
As such the ServiceUserMapping service dependency narrows the functionality
towards the more secure angle.
Should we thus drop the defaults because ServiceUserMapping dependency and
defaults fallback support are not equivalent from an API point of view ? Sounds
like throwing out the baby with the bath water.
Using filters we have a number of options, actually:
* @Reference(mapping.target=(subServiceName=dedicatedUserService))
Require mapping for the given sub service name
* @Reference(mapping.target=(!(subServiceName=*)))
Require a plain service name mapping
*
@Reference(mapping.target=(|(subServiceName=dedicatedUserService)(!(subServiceName=*))))
Ask for sub service name mapping, allowing fallback to plain service name
mapping
The question is just how we would handle allowing a falling back to the default
user mapping. Maybe we define a new service property {{default}} which is only
set for the default mapping ?
Whether we define an annotation to simplify the initial setup or not is another
question.
> 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
>
> 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)
