I already thought to the "equal strategy" solution, but I was not satisfied with the drawbacks. I did not understand at all that the 30-32 permissions were per class ant not accross all classes, I will see this again...
Concerning the manager, I will try to implement it. Thanx a lot for your responses! Keven On Jan 4, 1:33 pm, Johannes <[email protected]> wrote: > You have a limit of 30-32 per class, but not globally across classes. > You could for example allocate a certain bit range solely for the use > by plugins. > > The built-in masks are using bit 1-8, and I'd encourage you to keep > them. But that still leaves you with 23-25 remaining bits which you > can use for custom voters. These remaining bits can have different > meaning for different classes, but you can only have a total of 30 to > 32 different permissions per class. If you want plugins to be able to > bring new permission attributes, you should not let them choose the > bits which are linked to these attributes, but rather you should have > the plugin request a certain amount of bits, and then have a sort of > manager which allocates a bit range to the plugin. Note that you can > allocate the same bit range to different plugins if they are for > different classes. > > Example: > - Plugin1 processes the class "MyBundle/Entity/Post" needs three bits, > manager assigns bit range [9, 11]. > - Plugin2 processes the class "MyBundle/Entity/Thread" needs two bits, > manager assigns bit range [9, 10]. > - Plugin3 processes the class "MyBundle/Entity/Thread" needs one bit, > manager assigns bit 11. > > Range [1, 8] is used by the built-in AclVoter, and the bits 1-8 have > the same meaning for both classes (Post, and Thread). > > If the above solution works for you, that's the best way. If you still > need more permissions, there is another option, but it has some > drawbacks. Everytime, when you add an access control entry to the ACL > there is an optional parameter ($strategy). This let's you define how > bitmasks are compared against each other. If you set this to 'equal', > then an ACE will only match if the bits in each mask are identical. > This will give you effectively 2^32 different permissions. However, > there are disadvantages to this which is why it is not the default. > Namely, you cannot use cumulative permissions anymore. Something like > the following won't work anymore: > > $builder = new MaskBuilder(); > $builder->add('view')->add('edit'); > $acl->insertObjectAce($sid, $builder->get(), 0, true, 'equal'); > $acl->isGranted(array(MaskBuilder::MASK_VIEW), $sid); // > boolean(false) > > but you will have to write the following instead > > $acl->insertObjectAce($sid, MaskBuilder::MASK_VIEW, 0, true, 'equal'); > $acl->insertObjectAce($sid, MaskBuilder::MASK_EDIT, 0, true, 'equal'); > $acl->isGranted(array(MaskBuilder::MASK_VIEW), $sid); // boolean(true) > > This will increase the number of entries you have to store in the > database, and of course might have an impact on performance if you > have too many entries in an ACL. > > Kind regards, > Johannes > > On 4 Jan., 10:22, Keven <[email protected]> wrote: > > > > > > > > > I am porting an existing application to Sf2 and this application can > > be viewed, to simplify, as a file-system paradigm: there are multiple > > volumes, each containing multiple nested directories, which contain > > files. > > > The users can add, edit, move or delete files. But they can also > > change some metada, import from different sources, activate some > > functionalities, manage stats, usage, consult data about files, > > directories and volumes. > > > Our customers are very different from each other, so we can't rely on > > roles to check permissions, we need capability authorizations, not > > identity ones. So we handle users, groups and "dynamic roles" (bunch > > of permissions on class scope, applicable on chosen volumes, > > directories or files, for users or groups). > > > As our customers are big companies, the role of each user in the > > application is very limited: some are just able to moderate some > > metadata - but not create or edit metadata, while some are able to > > create and manage users, groups, "dynamic roles", volumes, ... > > > As you can see, we need a lot of different permissions which can't be > > based on base ones, as you suggested. Furthermore, the application is > > organized in plugins and third-party developers can provide plugins, > > with new permissions, new domain objects... We can't risk to have > > collisions between two permissions (or masks) in different plugins. > > > I think the same requirements are met in phpBB forums for example. > > > The 2 blocking problems in Sf2 Acl are: > > 1. There is a single global bitmask for permissions, so 30-32 > > permissions is the most you can expect > > 2. The permission mask is linked to a bitmask order (the 2 << n) in > > the code so plugins can't bring permissions being sure not to collide > > with another plugin's permission > > > For the 2: perhaps the Acl/Permission should provide a way to declare > > permissions without worry about the order: the mask is a hash table > > until it is stored in the database. At this time, it is transformed to > > a bitmask, and a new table come to store the relation between hash > > keys and bits order in the mask. > > > For the 1: the permissions could be associated to a namespace, so each > > namespace would benefit of 30-32 new free permission slots. Note that > > this proposition will solve the 2nd point too! > > > I hope I don't waste your time with my questions/propositions. > > > Regards.. > > > On Jan 4, 12:34 am, Johannes <[email protected]> wrote: > > > > 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
