The AclProvider itself is not aware of the PermissionMap; it only knows bitmasks, but not their meaning. If you use the same bitmask but with different meaning, then you have a security vulnerability. However, you can write one voter for each domain class, and each voter may have different permission maps. As long as not multiple voters are allowed to vote on the same class with overlapping bitmasks, you're fine.
I'm not sure though if you really need this, what is your use case for that many permissions? When you simply want to add a check if someone is allowed to activate something (a new attribute the voter understands), then you should be able to do this with the provided bitmasks. For example: PERMISSION_ACTIVATE = array(MaskBuilder::MASK_OWNER, MaskBuilder::MASK_MASTER, MaskBuilder::MASK_OPERATOR) You only need to add a MASK_ACTIVATE, if you want to be able to grant solely activation rights to a security identity. Kind regards, Johannes On 3 Jan., 22:35, Keven <[email protected]> wrote: > Ok, so my bundle has to provide its own MaskBuilder, its own > PermissionMap, and instantiate a new AclVoter. Thank you. > > There is still one thing I don't get : the masks provided by my custom > MaskBuilder are similar to those provided by the default MaskBuilder, > so how can we differentiate them (I mean: at the AclProvider level)? > > If my MaskBuilder provides a MASK_ACTIVATE = 8, and my PermissionMap a > permission PERMISSION_ACTIVATE with this single MASK_ACTIVATE, how > will > the AclProvider make the difference between my PERMISSION_ACTIVATE > mask with a value of 8, and a default "8" mask which means > PERMISSION_DELETE? > > I hope I don't bother you with stupid questions: I have the intuition > this paradigm is suitable for all Acl needs... but I don't see how > yet. ;) > > On Jan 3, 6:14 pm, Johannes <[email protected]> wrote: > > > The default AclVoter has only one permission map for all classes, but > > you can add as many voters as you like with custom permission maps > > which might only process objects of a certain class. In most cases > > though, you should be fine with extending the BasicPermissionMap, and > > the MaskBuilder class. > > > Kind regards, > > Johannes > > > On 3 Jan., 18:01, Keven <[email protected]> wrote: > > > > Like the Spring Security Acl, Sf2 Security Acl permissions are stored > > > in a bitmask. It means that no more than 32 (sometines 30) permissions > > > can be part of a acl, minus 7 native permissions included in the > > > BasePermissionMap => 23 to 25 free permission "slots". > > > > In a big (but not enormous) application, this can be fille very > > > quickly, particularly if some bundles bring domain object classes and > > > related custom permissions. > > > > Is that possible to have multiple permission maps in the same > > > application, where each stores only the permissions for a single > > > domain object class? > > > If not, how can we handle more than ~25 permissions, avoiding > > > collision between several bundles? > > > > (AFAIK Spring Securit doesn't bring any solution for this problem) > > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
