Well, another possibility would be to move the effective acl out of the
Store entirely. Have the Security implementation cache the effective acl
of a resource the first time it is accessed. When a resource changes
either clear the cache for all child resources or regenerate the
effective acls.
I can't decide if this is a cleaner solution or not, and I'm sure there
are problems I'm not thinking of.
-James
On Fri, 2004-10-08 at 03:21, Oliver Zeigermann wrote:
> I have had a closer look at all this and it just isn't easy. Main
> problem as usual are that there can be different stores possibly nesting
> each other. I doubt there is a simple *generic* solution...
>
> Maybe someone else with a bigger brain would like to persue this
> further, I do not seem to be up to the task...
>
> Oliver
>
> James Mason schrieb:
> > Thanks Jim, this does clear things up for me. I wasn't thinking of the
> > effectiveACL as being a separate property. Making it separate should
> > make granting a permission faster and obviate scenario #3.
> >
> > What I was trying to get at earlier was that the current logic for
> > checking effective permissions lives in
> > org.apache.slide.security.SecurityImpl (see hasPermission() on 493 in
> > CVS). If we change the way ACLs are are calculated we need to change the
> > logic there, and I was worried about a possible explosion of scenarios
> > that would need to be handled in that method.
> >
> >>>From your explanation it sounds like there are really only two
> > scenarios, so I'm feeling a lot better about this :).
> >
> > FYI Jim: for some reason email I'm getting from you on the list has your
> > address in the reply-to header instead of the mailing list's. Not sure
> > why, but maybe your email client is setting an explicit value for
> > reply-to and the list isn't changing it? Just thought you should know.
> >
> > -James
> >
> > On Thu, 2004-10-07 at 19:44, Jim Myers wrote:
> >
> >>I think you're thinking of getEffectiveAcl being outside the store. If it is
> >>part of your store implementation, it is your job to store effective acls
> >>during the grantPermission/revokePermission calls the same way you expect to
> >>find them in getEffectiveAcl. So you have:
> >>
> >>grant/revoke work as they do now, getEffectiveAcl does the calculation of
> >>effective acl from the individual aces on whatever ancestors
> >>
> >>grant/revoke always recompute and store an effective acl for all children
> >>whenever a new ace is set and they store it somewhere (as a new table, as an
> >>effecitve acl property, whatever) and getEffectiveAcl just retrieves it
> >>
> >>grant/revoke recompute the effective acl only on the current node and
> >>children that have acls set on them directly and stores them and
> >>getEffectiveAcl looks for effectiveacl entries up the tree until it finds
> >>one to return
> >>
> >>In all cases, the store implements a matched pair of set/get operations so
> >>there is never a case where getEffectiveAcl looks and can't find something.
> >>
> >>#1 only requires implementing the new getEffectiveAcl method - no changes to
> >>grant/revoke and no changes to the information being stored. #2 and #3 both
> >>require that grant/revoke be modified to store the effectiveAcl somewhere
> >>along with a matching getEffectiveAcl method.
> >>
> >>Does this make sense or have I missed your point?
> >>
> >> Jim
> >>
> >>----- Original Message -----
> >>From: "James Mason" <[EMAIL PROTECTED]>
> >>To: "Jim Myers" <[EMAIL PROTECTED]>
> >>Sent: Thursday, October 07, 2004 8:31 PM
> >>Subject: Re: Security Performance
> >>
> >>
> >>
> >>>On Thu, 2004-10-07 at 16:14, Jim Myers wrote:
> >>>
> >>>>Ah - OK. I think you could still create the getEffectiveAcl method
> >>>>signature
> >>>>and add a default implementation to the base store(s) -
> >>>>AbstractRDBMSStore
> >>>>for example - that just does the calcualtion as it is now. That would
> >>>>still
> >>>>allow existing stores to work as is (I think).
> >>>
> >>>This sounds good to me. I see three scenrios presented in this thread:
> >>>
> >>>1) The old (current) way that requires recursively checking parent
> >>>nodes.
> >>>2) Effective ACL that contains everything from all the parents.
> >>>3) Same as two, but the effective ACL is stored on some arbitrary parent
> >>>object (correct me if I'm wrong about this one).
> >>>
> >>>#1 and #2 seem easy (use Jim's suggestion above for #2). #3 seems to be
> >>>the problematic one. Maybe getEffectiveAcl could return null or throw an
> >>>exception to indicate that the parent node should be checked?
> >>>
> >>>-James
> >>>
> >>>
> >>>> Jim
> >>>>
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Oliver Zeigermann" <[EMAIL PROTECTED]>
> >>>>To: "Slide Developers Mailing List" <[EMAIL PROTECTED]>
> >>>>Sent: Thursday, October 07, 2004 6:18 PM
> >>>>Subject: Re: Security Performance
> >>>>
> >>>>
> >>>>
> >>>>>I guess what James refers to is that there would still be stores that
> >>>>>did
> >>>>>not support the effective ACL thing. They would have to be handled
> >>>>>differently.
> >>>>>
> >>>>>Oliver
> >>>>>
> >>>>>Jim Myers schrieb:
> >>>>>
> >>>>>
> >>>>>>I'm not sure I see the issue. I think you could essentially take most
> >>>>>>of
> >>>>>>the logic in the enumeratePermissions and hasPermissions and move it
> >>>>>>to
> >>>>>>the store. SecurityImpl would just be left with matching the effective
> >>>>>>ACLs with the user's name/roles/groups. Am I missing something?
> >>>>>>
> >>>>>> Jim
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>On Thu, 2004-10-07 at 06:54, Oliver Zeigermann wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>>Jim Myers schrieb:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>I'm thinking that I might still be able to store effective acls
> >>>>>>>>
> >>>>>>>>only > for
> >>>>>>>>
> >>>>>>>>>the ancestors but avoid the iterative calls up the resource tree
> >>>>>>>>>if I
> >>>>>>>>>can customize the implementation in the store (naively SELECT *
> >>>>>>>>>from
> >>>>>>>>>effectiveacls WHERE path IN ('a','a/b', 'a/b/c')) - perhaps not
> >>>>>>>>>too
> >>>>>>>>>much
> >>>>>>>>>of a performance hit versus storing them for each node
> >>>>>>>>
> >>>>>>>>I see, this would work for the db stores, but not for the file
> >>>>>>>>stores
> >>>>>>>>as
> >>>>>>>>there is an XML information LOB for each resource. So, you would
> >>>>>>>>still
> >>>>>>>>have to touch more of them.
> >>>>>>>
> >>>>>>>
> >>>>>>>If the customization was made as part of a store interface we could
> >>>>>>>optomize for implementations with more flexible query mechanisms.
> >>>>>>>Maybe
> >>>>>>>extending SecurityStore and altering enumeratePermissions(), then
> >>>>>>>modifying SecurityImpl (or whatever) to not check ancestors for that
> >>>>>>>implementation.
> >>>>>>>
> >>>>>>>One problem with this would be supporting different handling
> >>>>>>>mechanism.
> >>>>>>>We'd need several extension interfaces and lots of special-casing
> >>>>>>>code
> >>>>>>>in SecurityImpl.
> >>>>>>>
> >>>>>>>Hopefully this will spark someone else to come up with a better idea
> >>>>>>>:).
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>-James
> >>>>>>>
> >>>>>>>
> >>>>>>>>Oliver
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>but I agree that the key thing is to create a getEffectiveAcl()
> >>>>>>>>>mechanism that improves upon the current performance and allows
> >>>>>>>>>different trade-offs to be developed to meet expected usage.
> >>>>>>>>>
> >>>>>>>>>Thanks for taking this on!
> >>>>>>>>>
> >>>>>>>>> Jim
> >>>>>>>>>
> >>>>>>>>>----- Original Message ----- From: "Oliver Zeigermann"
> >>>>>>>>><[EMAIL PROTECTED]>
> >>>>>>>>>To: "Slide Developers Mailing List" <[EMAIL PROTECTED]>
> >>>>>>>>>Sent: Wednesday, October 06, 2004 6:25 PM
> >>>>>>>>>Subject: Re: Security Performance
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>My idea was to have effective ACLS with all nodes. Your idea
> >>>>>>>>>>sounds
> >>>>>>>>>>good as well, but it would still include checking more than one
> >>>>>>>>>>resource. Maybe and idea would be to have both options. Yours
> >>>>>>>>
> >>>>>>>>might be
> >>>>>>>>
> >>>>>>>>>>better if there are a lot of leaf resources with no ACL...
> >>>>>>>>>>
> >>>>>>>>>>Oliver
> >>>>>>>>>>
> >>>>>>>>>>Jim Myers wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>Are you suggesting calculating effective ACLs all the way down
> >>>>>>>>>>>the
> >>>>>>>>>>>tree or just to the last node where an ACL is set? I.e. at
> >>>>>>>>>>>run-time,
> >>>>>>>>>>>from a leaf node, I search up the tree until I find the ancestor
> >>>>>>>>
> >>>>>>>>that
> >>>>>>>>
> >>>>>>>>>>>has the effective ACL (which is the same for all of its
> >>>>>>>>>>>children)
> >>>>>>>>>>>versus every node stores its own effective ACL. Since I would
> >>>>>>>>>>>expect
> >>>>>>>>>>>most ACLs will get set high up in the tree, the former approach
> >>>>>>>>
> >>>>>>>>might
> >>>>>>>>
> >>>>>>>>>>>be a good compromise and minimize the storage required and the
> >>>>>>>>>>>potential delay of someone changes an ACL on /files for example.
> >>>>>>>>>>>
> >>>>>>>>>>> Jim
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>----- Original Message ----- From: "Oliver Zeigermann"
> >>>>>>>>>>><[EMAIL PROTECTED]>
> >>>>>>>>>>>To: "Slide Developers Mailing List"
> >>>>>>>>>>><[EMAIL PROTECTED]>
> >>>>>>>>>>>Sent: Wednesday, October 06, 2004 3:26 AM
> >>>>>>>>>>>Subject: Security Performance
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>Folks,
> >>>>>>>>>>>>
> >>>>>>>>>>>>I just had a closer look to security checking in Slide. I have
> >>>>>>>>>>>>seen
> >>>>>>>>>>>>there is some caching as well... Is it transactional?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Anyway, as all ancestors of the resource in question need to be
> >>>>>>>>>>>>checked and all entries are collected, the security checking
> >>>>>>>>>>>>does
> >>>>>>>>>>>>not seem to be fast, is it? I was wondering if Slide should not
> >>>>>>>>>>>>do
> >>>>>>>>>>>>what other systems do, namely along with the individual ACL
> >>>>>>>>>>>>store
> >>>>>>>>>>>>the *effective* ACL of an object as well. This effective ACL
> >>>>>>>>>>>>would
> >>>>>>>>>>>>contain the information of ancestors as well and would need to
> >>>>>>>>>>>>be
> >>>>>>>>>>>>newly computed with each change of the object ACL or the ACL of
> >>>>>>>>>>>>one
> >>>>>>>>>>>>of the ancestors. This would make access checking much
> >>>>>>>>>>>>faster...
> >>>>>>>>>>>>
> >>>>>>>>>>>>The idea behind this is ACL changes occur rarely, but checks
> >>>>>>>>>>>>very
> >>>>>>>>>>>>constanly.
> >>>>>>>>>>>>
> >>>>>>>>>>>>What do you think? I guess this should be doable with a
> >>>>>>>>>>>>reasonable
> >>>>>>>>>>>>effort...
> >>>>>>>>>>>>
> >>>>>>>>>>>>Oliver
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>---------------------------------------------------------------------
> >>>>>>>>
> >>>>>>>>>>>>To unsubscribe, e-mail:
> >>>>>>>>>>>>[EMAIL PROTECTED]
> >>>>>>>>>>>>For additional commands, e-mail:
> >>>>>>>>>>>>[EMAIL PROTECTED]
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>---------------------------------------------------------------------
> >>>>>>>>
> >>>>>>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>>>>>>>For additional commands, e-mail:
> >>>>>>>>>>>[EMAIL PROTECTED]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>---------------------------------------------------------------------
> >>>>>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>>>>>>For additional commands, e-mail:
> >>>>>>>>>>[EMAIL PROTECTED]
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>---------------------------------------------------------------------
> >>>>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>>>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>---------------------------------------------------------------------
> >>>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>---------------------------------------------------------------------
> >>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>---------------------------------------------------------------------
> >>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
