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]
