WorkflowPackageManagerImpl requires that the user creating workflow package has read access to /var/workflow/packages

[gicig]

Required Information

• [ ] AEM Version, including Service Packs, Cumulative Fix Packs, etc: 6.5.1
• [ ] ACS AEM Commons Version: 4.2.0
• [ ] Reproducible on Latest? yes

Expected Behavior

If user creating workflow package has read&write permissions for /var/workflow/packages/project1/tenant1/, it should be able to create packages there, even though it doesn't have any permissions for /var/workflow/packages

Actual Behavior

The user with permissions described above can not create packages for /var/workflow/packages/project1/tenant1/, unless it is granted read permissions for /var/workflow/packages/ - check here

Steps to Reproduce

Create user with permissions above and try to create a workflow package using WorkflowPackageManagerImpl#create(ResourceResolver , String, String, String...)

Links

https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/workflow/impl/WorkflowPackageManagerImpl.java

[joerghoh]

Seems to be caused by https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/workflow/impl/WorkflowPackageManagerImpl.java#L265

The detection if the "new" or the "legacy" path is used could be done on startup of the service; of course then you need to restart the service/instance when you migrate the workflows. But if that happens on the startup, you could use a session with elevated privileges to detect that and then the user does not have to have read access to /var/workflow/packages anymore.

[joerghoh]

@gicig Can you review the bugfix I provided in #2077 and check if it is working for you?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[davidjgonzalez]

Fixed via #2077

[gicig]

Sorry for not testing this earlier. Now that I did test it in my project I noticed something strange: acs-commons-workflowpackagemanager-service doesn't have read permissions on /var/workflow/packages. Please check https://drive.google.com/file/d/1q2y92bBgPzuGTZAjeYXPWIGVE6TsSkev/view?usp=sharing

Even though there is an allow permission under the respective rep:policy, useradmin doesn't show it does have read rights. Service resource resolver doesn't have those permissions either - getting resource from /var/workflow/package results in null.

However, when adding the permission through useradmin interface it can get that resource. Even though the rep:policy gets exact same allow permission: https://drive.google.com/open?id=16nJ6lCi7JPyH6hyivdsDLrSVlpWQfEEc

[joerghoh]

Strange. IIRC I heard that there were issues once when ACLs have been introduced with packages like this, that some internal cache got out of sync; adding a new (random) ACL fixed it. Can you test if you can reproduce the issue you reported and if adding a random ACL helps?

[gicig]

For acs-commons-workflowpackagemanager-service I added through CRX:

• jcr:read (there was a rep:policy with some ACEs) to one path under /content -> no change,
• a new ACL (there was no rep:policy at the moment) with jcr:read to one path under /content -> no change,
• a crx:replication to /var/workflow/package -> only new privilege in column Replicate is present in useradmin, no change in column Read

[joerghoh]

You tried my recommendation and added some random ACLs, but there was no effect and the required permissions /var/workflow/package were not there? In that case it's not this Oak issue, and we have to investigate further.