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 inhttp://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,
sb

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 inaf70ac8 ? 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.

Closed in favor of#8313