[
https://issues.apache.org/jira/browse/SLING-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15082770#comment-15082770
]
Carsten Ziegeler commented on SLING-5355:
-----------------------------------------
I think this tool needs to create the paths if they don't exist - who should
otherwise create them? The modules using the paths with the service users
clearly can't
I'm also not sure if an OSGi service setting the ACLs at runtime is a good
thing. This creates another dependency which is hard to track and even harder
to express. What happens if a module requiring the ACLs and users is starting
before this service? And these OSGi configurations can be arbitrarily changed
at runtime, which might create some chaos.
And more important it creates a security hole as anyone who is able to create
an OSGi configuration can simple add users and change ACLs at runtime - without
any further protection.
I would prefer a solution which is processed by the tool processing the
provisioning model and then creating "content" which is installed in the
repository. So it's a one time thing - done at build time.
> Create service users and ACLs from the provisioning model
> ---------------------------------------------------------
>
> Key: SLING-5355
> URL: https://issues.apache.org/jira/browse/SLING-5355
> Project: Sling
> Issue Type: New Feature
> Components: Service User Mapper
> Reporter: Bertrand Delacretaz
> Assignee: Bertrand Delacretaz
>
> As discussed in the "Removing loginAdministrative, how to test that, and
> service username conventions" thread on our dev list [1] we need to be able
> to create service users and set the corresponding ACLs from our provisioning
> model.
> This should be implemented using distinct utility classes, one for the users
> and one for the ACLs, that take simple mini-languages as input. This will
> allow for reusing these utilities in test code for example.
> I have made a suggestion for those mini languages in that thread, will copy
> them here once we agree.
> [1] http://markmail.org/message/kcvuhwfdald2dyuz
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)