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
