Root ACL permission about platform HOT 8 CLOSED

This functionality has not changed in the alpha2 code. It seems odd and slightly buggy the way it works. What is the point of the root permission if we cannot configure which roles have it? (we can configure who has it but we have no choice but to also give them every other permission in the system)

I checked through the commit that @yurio referenced this issue from and could not see anything that answered my question. Is it possible the wrong commit referenced this issue? The AclInterceptor class has not been updated since the initial commit and the role controller still calls saveRoleAcl.

from platform.

Sehr geehrte Dame, sehr geehrter Herr

Guten Tag und vielen Dank für Ihre Nachricht. Sie erreichen mich heute allerdings nicht wie gewohnt im Büro. Derzeit spiele ich Duracell und lade meine Batterien auf. Am 08. Juli bin ich wieder an meinem Arbeitsplatz.

Ihr Anliegen lässt sich nicht so lange aufschieben? Dann hilft Ihnen mein Kollege, Herr Pascal Kappeler, gerne weiter. Sie erreichen ihn zu den üblichen Bürozeiten per Mail [email protected] oder per Telefon +41 71 985 09 31.

Mit besten Grüssen und frohe Festtage
Jonas Hager

from platform.

To @LRotherfield:

It looks like there is a lack of documentation about ACL usage, we will fix it.
Now, about ACL permissions.

ACL has tree structure that means if you select tree node then all depended nodes will be selected automatically, but also you can select some of depended nodes without root node.

Default behaviour for actions without ACL is "deny", but possibly in future it will be customizable.

Root node specifies root of ACL tree, so, if you have it then you will have access to all actions including actions without ACL. This node should be selected only for admins and superadmins for debugging and some extra functionality, so regular users shouldn't have access to actions without ACL. If you want to allow access to such actions for regular users, you should specify ACL node using annotation @acl or configuration file acl.yml.

If you still have some questions - please, ask, we will answer ASAP.

from platform.

@yshyshkin thanks for the response and clarification.

Given your response, it seems to me that no users should be able to get root access just by having all other ACL permissions. Instead would it not be better to have an option to add "Access non ACL routes" permission to a role. Otherwise if one role (e.g admin) should have all permissions then they get root access automatically even though they probably should not have it as we want them to be under the same default behaviour as other roles (which as you have said is "deny").

from platform.

The problem with "Access non ACL routes" permission is in security. F.e. application uses some external bundle with lots of actions and only a few of which has configured ACLs and permissions. Now lets assume that this bundle was updated and some important action was added. In case of "Access non ACL routes" permission users will be allowed to run this action and theoretically they can damage DB and whole installation. To prevent that Oro bundles must specify ACLs for external bundle actions which should be available for regular users. Good example is ACL for Bazinga/ExposeTranslationBundle in Oro/JsFormValidationBundle.

from platform.

I think we are both talking about the same thing, because you have highlighted a similar issue to the one I am talking about (at least the issue I am trying to convey). If the admin role has all ACL permissions then they have root permissions too which means the admin users could run the DB breaking actions. If you stop users from ever getting root ACL permission then this would never happen (or if root acl did not allow non acl actions to be run).

The "Access non ACL routes" permission I suggested would be for a developer account only so that no other users (no matter what ACL privileges they have) could ever run actions without ACL configured.

from platform.

For developers you can create separate role and all required ACL should be added in developed bundle (in fact, it's even better - if developers have "Access non ACL routes" permission, they can just forget to add it to ACL because it already works).

Anyway, thank you for proposition - we will discuss it and will update this thread.

from platform.

We are going to implement Access Strategy (allow/deny) on role level. This will cover access strategy to resources that are not defined in ACL.

from platform.