[
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363013#comment-14363013
]
Felix Meschberger edited comment on SLING-4461 at 3/16/15 10:12 AM:
--------------------------------------------------------------------
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 ?
So, with filters we can cover everything from most narrow requirements to
broadest possible openness as supported by the API.
Whether we define an annotation to simplify the initial setup or not is another
question.
Last but not least: The fall back defaults are not really less deterministic
than not having them. For one thing the fall-back mechanism fully determined:
# If a subservice name is required check that mapping first
# Then go for service name only mapping
# Then fall back to default mapping (if configured)
The non-determinism comes from the the fact, that configuration may be updated
at any time. But this is a fundamental tenet of the OSGi framework and as such
is not really a problem. In fact having the ServiceUserMapped service allows to
actually cope with this dynamism in that a component may be taken out of
service if a mapping is removed.
was (Author: fmeschbe):
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)
