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