[
https://issues.apache.org/jira/browse/JCRVLT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074112#comment-17074112
]
Georg Henzler edited comment on JCRVLT-427 at 4/3/20, 10:42 AM:
----------------------------------------------------------------
In theory you could argue this check is not needed at all because the code of
the install hook runs with the exact same user as the installation (hence that
code can only affect content that the package content itself also could
affect).
But if we want to keep the check: What about just checking if the user can
write at a certain path? For Apache Sling-based systems that would be /apps -
and with the Sling OSGi installer, anybody that can write to /apps can run
arbitrary code via bundles in the same way as an install hook can run arbitrary
code. That path could be configurable for non-Sling setups. Also there is no
need to "leave the defaults `system`, `admin` and `administrstors`" in because
they also all have permissions to write to /apps.
The big advantage of this approach is that for most users that try to work with
a "deployment-admin-user" will not have to know about this special handling
because they will automatically give that "deployment-admin-user" write rights
to /apps (as it is evident that is needed).
Edit (little addition): So for setups using the composite nodestore it might
sound like potentially this approach does not work (since /apps is ready-only
there), but it is still possible due to the fact that for the composite
nodestore {{session.hasPermission("/apps", Session.ACTION_SET_PROPERTY)}} will
still return {{true}} - to check for the composite nodestore we use
session.hasCapability(...) elsewhere (not applicable for this case).
was (Author: henzlerg):
In theory you could argue this check is not needed at all because the code of
the install hook runs with the exact same user as the installation (hence that
code can only affect content that the package content itself also could
affect).
But if we want to keep the check: What about just checking if the user can
write at a certain path? For Apache Sling-based systems that would be /apps -
and with the Sling OSGi installer, anybody that can write to /apps can run
arbitrary code via bundles in the same way as an install hook can run arbitrary
code. That path could be configurable for non-Sling setups. Also there is no
need to "leave the defaults `system`, `admin` and `administrstors`" in because
they also all have permissions to write to /apps.
The big advantage of this approach is that for most users that try to work with
a "deployment-admin-user" will not have to know about this special handling
because they will automatically give that "deployment-admin-user" write rights
to /apps (as it is evident that is needed).
Edit (little addition): So for setups using the composite nodestore it might
sound like potentially this approach does not work (since /apps is ready-only
there), but it is still possible due to the fact that for the composite
nodestore {{session.hasPermission("/apps", Session.ACTION_SET_PROPERTY)}} will
still return {{true}} - to check for the composite nodestore we use
{{session.hasCapability("addNode", appsNode, new Object[] \{ "nt:folder" \});
}} elsewhere (not applicable for this case).
> Allow installation of packages with hook for users without admin privileges
> ---------------------------------------------------------------------------
>
> Key: JCRVLT-427
> URL: https://issues.apache.org/jira/browse/JCRVLT-427
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
> Priority: Major
> Fix For: 3.4.6
>
>
> Currently due to the check in
> https://github.com/apache/jackrabbit-filevault/blob/e257001ec22ea06bcc987cbf79f0cc9b15c4e186/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ZipVaultPackage.java#L184
> packages containing a hook can only be installed by admins.
> Although I do understand the intent of that I think this is not flexible
> enough as currently that only gives the rights to users "admin", "system" or
> members of group "administrators". Instead there should be an OSGi
> configuration which allows to configure to grant the right to install
> packages with hooks to other groups as well!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
