Policy.yaml | abstained permission is granted

Using Neos & Flow
1

Hi,
it seems like I am having trouble understanding policies. An EditNode-permission is granted when the security:showeffectivepolicy-command states that it should be abstained. Denying the privilegeTarget works as expected.

This is my policy.yaml

privilegeTargets:

  'Neos\ContentRepository\Security\Authorization\Privilege\Node\EditNodePrivilege':
    'Qweb.AdmTool:Edit.M05PersonIntro':
      matcher: 'nodeIsOfType("Qweb.AdmTool:Content.M05PersonIntroTeaser")'

roles:
  'Neos.Neos:Editor': #Administrator inherits from editor
    privileges:
      - privilegeTarget: 'Qweb.AdmTool:Edit.M05PersonIntro'
        permission: GRANT

# why is the following needed? 
#  'Qweb.AdmTool:SalesPeople': 
#    privileges:
#      - privilegeTarget: 'Qweb.AdmTool:Edit.M05PersonIntro'
#        permission: DENY

Neos consideres the permisson ABSTAINed, just as I expect it.

./flow security:showeffectivepolicy --roles=Qweb.AdmTool:SalesPeople
Please specify the required argument "privilegeType": method
Effective Permissions for the roles Qweb.AdmTool:SalesPeople, Neos.Neos:AbstractEditor, Neos.ContentRepository:Administrator, Neos.ContentRepository:InternalWorkspaceAccess, Neos.Flow:
AuthenticatedUser, Neos.Flow:Everybody 
...
Qweb.AdmTool:Edit.M05PersonIntro                                       ABSTAIN
...

BUT: I can edit the text property of the Node when I log in with SalesPeople role. Why? Is there some other privilegetarget that overrides the EditNodePrivilege (eg Neos.Neos:Backend.EditContent, wich is granted)?

What would be the proper way to implement this?

2

Hello Runa,

if sales people are editors via parentRole (which is likely because they logged in to neos and edited a node) then the privilege is granted because of the inherited role.

I expect you will find some Policy.yaml configuration like this or a even more indirect:

roles:
 'Qweb.AdmTool:SalesPeople':
     parentRoles: ['Neos.Neos:Editor']

This is also the reason why the second privilege is needed. Access is only granted if at least one grant and no deny is given.

3

Hi Martin,

thank you for your response.
It appears that the reason is a dynamically generated policy, wich adds privileges after the general policy is applied, wich also explains that the permission is granted although the flow command lists it as abstained :slight_smile: