I just wanted to tell you guys, in case anyone is in the same situation, that I've implemented this approach. It's not that much work as I thought, and it works like a charm. I'm using now two ACEs for each object and SID, and two ACEs for each field of the object and SID. One ACE for ALLOW permissions, and one ACE for DENY permissions. If I want to inherit some permission, I just remove the permission of the mask and let it bubble up the check for the parent security identity.
I'll try to reproduce the issue I had before when I get back home. Thanks! 2011/4/11 Gustavo Adrian <comfortablynum...@gmail.com> > Yes, I thought about that. I've been avoiding that approach, but I think > now it could help. That way I wouldn't need to delete and insert the ACE > again. I could update it and that's it. It's a little bit more of work but > I'll give it a try. I'll get back with comments about it. And I'll try to > reproduce the mentioned issue in a test too. > > > Thanks. > > > 2011/4/9 Johannes Schmitt <schmitt...@gmail.com> > >> I think even if it is a bit more work when changing permissions, you >> should definitely look into cumulative permissions since this will increase >> the performance of your application. It should be sufficient to have one ACE >> with all granting, and one ACE with all denying permissions for each >> security identity. >> >> Only changing the granting flag might cause problems in combination with >> the granting strategy, and I don't see the use case for it right now. >> >> Kind regards, >> Johannes >> >> >> >> On Fri, Apr 8, 2011 at 10:35 PM, Gustavo Adrian < >> comfortablynum...@gmail.com> wrote: >> >>> Of course. I'll try to reproduce the issue in a test. In the meantime I >>> want to clarify that I don't use cumulative permissions, because I need to >>> configure for each permission if it's an ALLOW or DENY entry, and it's >>> easier this way. Taking this fact into account, If I could update the >>> "granting" property of an ACE, I'd just update the existing ACE instead of >>> deleting and inserting it on the ACL. I've noticed that you can update a >>> field ACE passing the following properties to the "updateObjectFieldAce" >>> method of the Acl class: >>> >>> $index, $field, $mask, $strategy = null >>> >>> Could it be an issue if we add an additional property ($granting) to >>> update the granting property of the ACE or this could be a problem at some >>> point of the update? if it wouldn't be an issue I could try to add the >>> functionality, but first I'd like to be sure if there's a technical reason >>> to not update the $granting property of an ACE. >>> >>> >>> Thanks! >>> >>> Best regards. >>> >>> 2011/4/8 Johannes Schmitt <schmitt...@gmail.com> >>> >>>> It would be nice if you can provide a failing test case in >>>> MutableAclProviderTest, otherwise just create a ticket, and I'll take a >>>> look >>>> at it. >>>> >>>> Johannes >>>> >>>> >>>> On Fri, Apr 8, 2011 at 9:43 PM, Gustavo Adrian < >>>> comfortablynum...@gmail.com> wrote: >>>> >>>>> MySQL logs show: >>>>> >>>>> 2940 Query START TRANSACTION >>>>> 2940 Query UPDATE acl_entries SET ace_order = 4 WHERE id = 464 >>>>> 2940 Query UPDATE acl_entries SET ace_order = 3 WHERE id = 465 >>>>> 2940 Query UPDATE acl_entries SET ace_order = 3 WHERE id = 466 >>>>> 2940 Query UPDATE acl_entries SET ace_order = 1 WHERE id = 479 >>>>> 2940 Query rollback >>>>> >>>>> >>>>> It first changes ace_order's, so if I deleted the entry with ace_order >>>>> = 1, at the time of synchronizing changes in the DB it first updates >>>>> ace_order fields, so the ACE I deleted is still there (with ace_order = 1 >>>>> too). This is, of course, for ACEs that are affected for the same unique >>>>> index, which have this fields: class_id, object_identity_id, field_name >>>>> and >>>>> ace_order. >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> 2011/4/8 Gustavo Adrian <comfortablynum...@gmail.com> >>>>> >>>>>> Hi all, >>>>>> >>>>>> During the update process of fields ACEs I'm getting this error: >>>>>> >>>>>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry >>>>>> '12-1106-entityTypeFriendly-1' for key >>>>>> 'UNIQ_46C8B806EA000B103D9AB4A64DEF17BCE4289BF4' >>>>>> >>>>>> I explain what I'm doing: As I allow to change the type of granting of >>>>>> the permission (allow or deny), and I didn't find a way to update the >>>>>> granting property of an ACE with acl methods like "updateObjectFieldACE" >>>>>> or >>>>>> the like, I'm just deleting the ACE and inserting it again on the ACL >>>>>> with >>>>>> the new value for the granting property. I do all this stuff for every >>>>>> field >>>>>> and, at the end, I update the ACL with $aclProvider->updateACL($acl); . >>>>>> Could this way of updating the granting property of an ACE bring this >>>>>> exception? >>>>>> >>>>>> I'm looking at the MutableAclProvider and I see that the >>>>>> updateXXXProperty methods first insert new ACEs and finally delete old >>>>>> ACEs >>>>>> (the ones which were deleted from the ACL). Could this mean that, as I >>>>>> deleted and inserted a new ACE from an ACL at the same time, at the >>>>>> moment >>>>>> of the update on the DB it first try to insert the new ACE with the same >>>>>> ace_order as the one that is going to be deleted? it's just a guess. I'm >>>>>> trying to trace the error so I can give further details. >>>>>> >>>>>> Is there a way to update the granting property of an ACE so I can >>>>>> update the ACE instead of deleting it an reinserting it again? >>>>>> >>>>>> >>>>>> >>>>>> Thanks in advance! >>>>>> >>>>> >>>>> -- >>>>> 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 users" group. >>>>> To post to this group, send email to symfony-users@googlegroups.com >>>>> To unsubscribe from this group, send email to >>>>> symfony-users+unsubscr...@googlegroups.com >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/symfony-users?hl=en >>>>> >>>> >>>> -- >>>> 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 users" group. >>>> To post to this group, send email to symfony-users@googlegroups.com >>>> To unsubscribe from this group, send email to >>>> symfony-users+unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/symfony-users?hl=en >>>> >>> >>> -- >>> 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 users" group. >>> To post to this group, send email to symfony-users@googlegroups.com >>> To unsubscribe from this group, send email to >>> symfony-users+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/symfony-users?hl=en >>> >> >> -- >> 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 users" group. >> To post to this group, send email to symfony-users@googlegroups.com >> To unsubscribe from this group, send email to >> symfony-users+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en >> > > -- 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 users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
