[Acl] altered the behaviour of RoleSecurityIdentity #5076
Conversation
|
This change has been rejected before (see #1748). @schmittjoh may be you could explain what vulnerability it would introduce and add a comment in the file ? |
|
Not allowing this change makes ACLs useless if you use Roles from a database. as documented in http://symfony.com/doc/master/cookbook/security/entity_provider.html#managing-roles-in-the-database . Could someone elaborate on the security vulnerability exposed by this change? We intend to setup an ACL based system relying heavily on Roles stored in the database. Of course, I could reimplement the ACL system so it does what we need, but this simple change in the default system fixes the problem. I can think of at least 2 alternative fixes, one of which would involve changing some code in Symfony\Component\Security\Acl\Domain\SecurityIdentityRetrieval; the other would involve changing our user implementation to return an array of Strings from User::getRoles(). However, I have no idea if that would break other compatibility. So, once again: please elaborate on the security vulnerability. After spending 1-2 days digging through the code to find this bug, i can't see any vulnerability. However, @schmittjoh will certainly know his code better. regards, |
|
Although I won't mark it as a security vulnerability, it still renders Role-based ACLs unusable if Roles are coming from the ORM instead of config.yml, as @binabik said. I have just ran into such a problem and discussed it on the Symfony2 Google Groups list: https://groups.google.com/forum/?fromgroups=#!topic/symfony2/kviy-DKUSOI |
|
After making my modifications in my RoleHierarchy class to return an array of strings instead of an array of MyRole entities, the core RoleVoter stops working. Please solve this issue somehow, this makes ORM-based roles totally unworthy. |
|
@schmittjoh could you explain exactly why you rejected this change in af70ac8 ? We currently have at least 3 PR asking for this change (as well as a few closed ones). Having the explanation would avoid further ones. |
The documentation seems to assume the implementation present in commit symfony/symfony#1673, which reverted soon after due to a potential, but undisclosed security hole (citation @schmittjoh in symfony/symfony@af70ac8). This incorrect documentation has likely been the source of many of the following issues: * symfony/symfony#1538 - [ACL RoleSecurityIdentity] check if instance of Role * symfony/symfony#1748 - Replace Role to RoleInterface for RoleSecurityIdentity * symfony/symfony#4309 - Issue related to custom group (role) and ACL/ACE * symfony/symfony#5026 - potential bug in Symfony\Component\Security\Acl\Domain\RoleSecurityIdentity * symfony/symfony#5076 - [Acl] altered the behaviour of RoleSecurityIdentity * symfony/symfony#5171 - Fix/role security identity * symfony/symfony#5303 - [Security] Check for RoleInterface instead of Role object in RoleSecurityIdentity * symfony/symfony#5909 - Allow Custom Roles to implement the RoleInterface * symfony/symfony#6012 - Securityidentity fix
|
Closed in favor of #8313 |
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: 5026
Todo: -
License of the code: MIT
Documentation PR: -
Implemented the change I documented in ticket #5206: the constructor checks for an instance of RoleInterface rather than Role.