[ 
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353031#comment-14353031
 ] 

Marius Petria commented on SLING-4461:
--------------------------------------

The way I see it there are two problems:
1. Overlapping concerns: an "administrator" cannot set a default for a bundle 
and expect everything to work because some bundles might not start. 

This can be fixed using the extended DS annotation as you suggested.

2. If one sets up fallbacks and subServices for a bundle then it can happen 
that the same code executes with different privileges. 

I can imagine the scenario of a cleanup service that deletes all files that is 
sees, older than 10 days in a folder. It does the execution with a 
cleanupSubService.  However if a bundle fallback is configured and it can see 
more files than the cleanupSubService then it will delete more files during the 
startup period when the cleanupSubService is not yet loaded and the fallback is 
used. This might be not the perfect example but it shows the kind of issues 
that can come up.

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

Reply via email to