You are viewing a plain text version of this content. The canonical link for it is here.

Posted to slide-dev@jakarta.apache.org by Oliver Zeigermann <ol...@zeigermann.de> on 2004/10/06 09:26:01 UTC

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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by James Mason <ma...@apache.org>.

Oliver,

Sounds good to me.

-James

Oliver Zeigermann wrote:
> 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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Oliver Zeigermann <ol...@zeigermann.de>.

This might work when caching is done in the Security layer, not in the 
stores. This is because stores can not communicate (can they?) to decide 
which cache entry to invalidate. E.g. if an ancector object in another 
store having inheritable settings gets changed, all it's successors - 
also the ones in other stores - must be invalidated.

This required access to the transaction manager from this layer. Maybe 
using the Synchrionization interface. Is this available in Slide?

Anyway, caching seems to be the better idea to me :)

Oliver

James Mason schrieb:

> 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" <ma...@apache.org>
>>>>To: "Jim Myers" <ji...@verizon.net>
>>>>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" <ol...@zeigermann.de>
>>>>>>To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>>>>>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"
>>>>>>>>>>><ol...@zeigermann.de>
>>>>>>>>>>>To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>>>>>>>>>>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"
>>>>>>>>>>>>><ol...@zeigermann.de>
>>>>>>>>>>>>>To: "Slide Developers Mailing List" 
>>>>>>>>>>>>><sl...@jakarta.apache.org>
>>>>>>>>>>>>>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: 
>>>>>>>>>>>>>>slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>>>>>>For additional commands, e-mail: 
>>>>>>>>>>>>>>slide-dev-help@jakarta.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>>>>>For additional commands, e-mail: 
>>>>>>>>>>>>>slide-dev-help@jakarta.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>>>>For additional commands, e-mail: 
>>>>>>>>>>>>slide-dev-help@jakarta.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: slide-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-user-help@jakarta.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: Security Performance

Posted by James Mason <ma...@apache.org>.

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" <ma...@apache.org>
> >>To: "Jim Myers" <ji...@verizon.net>
> >>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" <ol...@zeigermann.de>
> >>>>To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> >>>>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"
> >>>>>>>>><ol...@zeigermann.de>
> >>>>>>>>>To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> >>>>>>>>>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"
> >>>>>>>>>>><ol...@zeigermann.de>
> >>>>>>>>>>>To: "Slide Developers Mailing List" 
> >>>>>>>>>>><sl...@jakarta.apache.org>
> >>>>>>>>>>>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: 
> >>>>>>>>>>>>slide-dev-unsubscribe@jakarta.apache.org
> >>>>>>>>>>>>For additional commands, e-mail: 
> >>>>>>>>>>>>slide-dev-help@jakarta.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>---------------------------------------------------------------------
> >>>>>>>>
> >>>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>>>>>>>>For additional commands, e-mail: 
> >>>>>>>>>>>slide-dev-help@jakarta.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>---------------------------------------------------------------------
> >>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>>>>>>>For additional commands, e-mail: 
> >>>>>>>>>>slide-dev-help@jakarta.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>---------------------------------------------------------------------
> >>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>---------------------------------------------------------------------
> >>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>---------------------------------------------------------------------
> >>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>---------------------------------------------------------------------
> >>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-user-help@jakarta.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: Security Performance

Posted by Oliver Zeigermann <ol...@zeigermann.de>.

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" <ma...@apache.org>
>>To: "Jim Myers" <ji...@verizon.net>
>>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" <ol...@zeigermann.de>
>>>>To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>>>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"
>>>>>>>>><ol...@zeigermann.de>
>>>>>>>>>To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>>>>>>>>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"
>>>>>>>>>>><ol...@zeigermann.de>
>>>>>>>>>>>To: "Slide Developers Mailing List" 
>>>>>>>>>>><sl...@jakarta.apache.org>
>>>>>>>>>>>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: 
>>>>>>>>>>>>slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>>>>For additional commands, e-mail: 
>>>>>>>>>>>>slide-dev-help@jakarta.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>>>For additional commands, e-mail: 
>>>>>>>>>>>slide-dev-help@jakarta.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>>For additional commands, e-mail: 
>>>>>>>>>>slide-dev-help@jakarta.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: Security Performance

Posted by James Mason <ma...@apache.org>.

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" <ma...@apache.org>
> To: "Jim Myers" <ji...@verizon.net>
> 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" <ol...@zeigermann.de>
> >> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> >> 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"
> >> >>>> > <ol...@zeigermann.de>
> >> >>>> > To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> >> >>>> > 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"
> >> >>>> >>> <ol...@zeigermann.de>
> >> >>>> >>> To: "Slide Developers Mailing List" 
> >> >>>> >>> <sl...@jakarta.apache.org>
> >> >>>> >>> 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: 
> >> >>>> >>>> slide-dev-unsubscribe@jakarta.apache.org
> >> >>>> >>>> For additional commands, e-mail: 
> >> >>>> >>>> slide-dev-help@jakarta.apache.org
> >> >>>> >>>>
> >> >>>> >>>>
> >> >>>> >>>
> >> >>>> >>>
> >> >>>> >>>
> >> >>>> ---------------------------------------------------------------------
> >> >>>> >>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> >>>> >>> For additional commands, e-mail: 
> >> >>>> >>> slide-dev-help@jakarta.apache.org
> >> >>>> >>>
> >> >>>> >>>
> >> >>>> >>
> >> >>>> >>
> >> >>>> >> ---------------------------------------------------------------------
> >> >>>> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> >>>> >> For additional commands, e-mail: 
> >> >>>> >> slide-dev-help@jakarta.apache.org
> >> >>>> >>
> >> >>>> >>
> >> >>>> >
> >> >>>> >
> >> >>>> > ---------------------------------------------------------------------
> >> >>>> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> >>>> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >> >>>> >
> >> >>>> >
> >> >>>>
> >> >>>>
> >> >>>> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> >>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> >>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> >
> > 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: Security Performance

Posted by Jim Myers <ji...@verizon.net>.

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).

  Jim


----- Original Message ----- 
From: "Oliver Zeigermann" <ol...@zeigermann.de>
To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
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"
>>>> > <ol...@zeigermann.de>
>>>> > To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>>> > 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"
>>>> >>> <ol...@zeigermann.de>
>>>> >>> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>>> >>> 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: slide-dev-unsubscribe@jakarta.apache.org
>>>> >>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> ---------------------------------------------------------------------
>>>> >>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>> >>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>> >
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Oliver Zeigermann <ol...@zeigermann.de>.

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"
>>> > <ol...@zeigermann.de>
>>> > To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>> > 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"
>>> >>> <ol...@zeigermann.de>
>>> >>> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>> >>> 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: slide-dev-unsubscribe@jakarta.apache.org
>>> >>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>> 
>>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> >>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>> >
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Jim Myers <ji...@verizon.net>.

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"
>> > <ol...@zeigermann.de>
>> > To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>> > 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"
>> >>> <ol...@zeigermann.de>
>> >>> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>> >>> 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: slide-dev-unsubscribe@jakarta.apache.org
>> >>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> >>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>> >>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by James Mason <ma...@apache.org>.

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" 
> > <ol...@zeigermann.de>
> > To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> > 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" 
> >>> <ol...@zeigermann.de>
> >>> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> >>> 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: slide-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Oliver Zeigermann <ol...@zeigermann.de>.

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.

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" 
> <ol...@zeigermann.de>
> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> 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" 
>>> <ol...@zeigermann.de>
>>> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>>> 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: slide-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Jim Myers <ji...@verizon.net>.

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

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" <ol...@zeigermann.de>
To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
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" 
>> <ol...@zeigermann.de>
>> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
>> 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: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Oliver Zeigermann <ol...@zeigermann.de>.

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" 
> <ol...@zeigermann.de>
> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> 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: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Jim Myers <ji...@verizon.net>.

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" <ol...@zeigermann.de>
To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Oliver Zeigermann <ol...@zeigermann.de>.

Martin Holz schrieb:

> Oliver Zeigermann <ol...@zeigermann.de> writes:
> 
> 
>>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...
> 
> 
> Security is a important performance bottleneck now. 
> 
> Would a ACL change of the root node result in a iteration over the complete
> tree? If you do this in a transaction, the store is blocked for a long time.
> 

Correct. This is the drawback of this...

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Security Performance

Posted by Martin Holz <ho...@fiz-chemie.de>.

Oliver Zeigermann <ol...@zeigermann.de> writes:

> 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...

Security is a important performance bottleneck now. 

Would a ACL change of the root node result in a iteration over the complete
tree? If you do this in a transaction, the store is blocked for a long time.


Martin
 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org