[jira] [Created] (SLING-3057) Ghosted reference to dependent bundle after .java script compilation prevents complete uninstallation

[Mark Adamcin (JIRA)]

Mark Adamcin created SLING-3057:
---

 Summary: Ghosted reference to dependent bundle after .java script 
compilation prevents complete uninstallation
 Key: SLING-3057
 URL: https://issues.apache.org/jira/browse/SLING-3057
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting Java 2.0.6
Reporter: Mark Adamcin


It appears that a lock is established on the cache directory of any bundle 
which is imported by a compiled .java script that prevents complete 
uninstallation of the dependent bundle, even after reinstallation of the 
bundle. 

The reinstalled bundle creates a new distinct cache folder under 
launchpad/felix, while the uninstalled cache folder remains write protected.

Subsequent recompilation of the .java script after reinstallation of the bundle 
fails due to missing .class files, with the message: " resolves to 
a package.". 

Restarting the Dynamic ClassLoader Support bundle or the Scripting Java bundle 
fails to force a recompilation using the newly reinstalled bundle, however a 
complete application restart will force the old cache folder to be garbage 
collected, and the .java script will compile correctly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [GSoC2013] Access Control for Cassandra ResourceProvider

[Ian Boston]

Hi Mike,
Thanks for the pointer.

On 12 September 2013 14:58, Mike Müller  wrote:
> Hi
>
> The common way to solve such an access control for a provider like
> the Cassandra resource provider is the new ResourceAccessSecurity
> service. This is implemented in the bundle resourceaccesssecurity
> (at this time only read rights will be checked).

Incidentally, how will other rights be enforced ?
the update pattern is resource.adaptTo(ModifiableValueMap.class)

would the adapter factory check that the current user has write access
to the resource before they can get their hands on a
ModifiableValueMap ?

Best Regards
Ian


 All you have to do is to
> implement the SPI ResourceAccessGate for the Cassandra provider
> and set the provider.useResourceAccessSecurity property to true
> for your ResourceProvider.
> By time resourceaccesssecurity will also implement create, modify
> And delete rights.
>
> Best regards
> mike
>
>> -Original Message-
>> From: Dishara Wijewardana [mailto:ddwijeward...@gmail.com]
>> Sent: Thursday, September 12, 2013 2:25 PM
>> To: dev@sling.apache.org
>> Subject: Re: [GSoC2013] Access Control for Cassandra ResourceProvider
>>
>> Hi Ian
>>
>>
>> On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston  wrote:
>>
>> > Hi Dishara,
>> > To make the Cassandra Resource Provider really useful I think we need
>> > to add access control. I think the best way of doing this is to borrow
>> > some concepts from Jackrabbit access control.
>> >
>> >
>> The following algorithms, and etc does sling already have any
>> implementation of it. If so I can reuse them. Since sling has few providers
>> I believe they probably have some common interface.
>>
>>
>> > Take a deep breath, and you will see why I left this till last.
>> >
>> > I think we should provide path base access control, which inherits
>> > from parent resources in the path. At every level there is a an
>> > ordered list of access control entries each access control entry (ACE)
>> > being either an allow entry or a deny entry. What is allowed or denied
>> > is defined in a 32bit bitmap with each bit representing 1 permission,
>> > so we can have upto 32 permissions. Each ACE specifies a single
>> > principal. So an ACL consists of a ordered list of ACE's each one
>> > bound to a principal.
>> >
>> > A user has a set of principals, so to resolve the ACL at any one path
>> > for a user the global ACL is filtered to contain only the ACE's with
>> > principals that the user has.
>> >
>> > Computing a final access control bitmap for a user at a location
>> > requires ordered processing of all the ACEs relevant to the user at
>> > the current path and then all ancestors.
>> >
>> > The pseudo algorithm to calculate the a grant bitmap and a deny bitmap
>> > at any level is:
>> >
>> > function getCurrentLevelBitmaps(currentPath):
>> >   int grants = 0;
>> >   int denies = 0;
>> >   for all ACEs in the ACL at the currentPath:
>> > if the user has the principal of the current ACE:
>> >   int toGrant = 0;
>> >   int toDeny = 0;
>> >   if the ACE is a grant:
>> > toGrant = the ACE bitmap;
>> >   else:
>> > toDeny = the ACE bitmap;
>> >   toGrant = toGrant & ~denies;
>> >   toDeny = toDeny & ~grants;
>> >   grants = grants | toGrant;
>> >   denied = denies | toDenies;
>> >   return (grants, denies);
>> >
>>
>> - Can you please tell me how to calculate the ACE bitmap ?
>> - Also I will be more clear if you can provide a sample value for the input
>> and output of this function ? i.e When currentPath=
>> /content/cassandra/foo/bar  it returns grants=? denies=? some actual values
>> just for my understanding.
>>
>>
>> > To combine what is granted at the child level with what is granted at
>> > a parent level we need to mask the parent level with the deny at the
>> > child level.
>> >
>> > eg
>> >  toGrant = grantedAtParent & ~denies;
>> >  toDeny = deniedAtParent & ~grants;
>> >  grants = grants | toGrant;
>> >  denied = denies | toDenies;
>> >
>> > The simplest way of achieving this is to use recursion again in pseudo
>> > code:
>> >
>> >function buildAtLevel():
>> > if not root level:
>> >  (grantedAtParent, deniedAtParent) =
>> > buildAtLevel(getParentLevel(currentLevel));
>> > (grants, denies) = getCurrentLevelBitmaps(currentLevel);
>> > toGrant = grantedAtParent & ~denies;
>> >toDeny = deniedAtParent & ~grants;
>> >grants = grants | toGrant;
>> >denied = denies | toDenies;
>> >return (grants, denied);
>> >
>> >
>> > There are some optimisations you can apply here, and there are plenty
>> > of opportunities to cache intermediate bitmaps in memory. Just caching
>> > the ACL reduces resolution to bitwise operations.
>> >
>> > Pri

Re: [GSoC2013] Access Control for Cassandra ResourceProvider

[Ian Boston]

Hi

On 12 September 2013 13:24, Dishara Wijewardana  wrote:
> Hi Ian
>
>
> On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston  wrote:
>
>> Hi Dishara,
>> To make the Cassandra Resource Provider really useful I think we need
>> to add access control. I think the best way of doing this is to borrow
>> some concepts from Jackrabbit access control.
>>
>>
> The following algorithms, and etc does sling already have any
> implementation of it. If so I can reuse them. Since sling has few providers
> I believe they probably have some common interface.



There is not, or at least, not in a way that is exposed. There is an
implementation inside Jackrabbit, but it is tightly coupled to
Jackrabbit and more complex than the simple system below.

Once implemented, this access control system may be exposed as a
ResourceAccessGate, but since (IIRC) imposing anything other than read
access control has not been done, the CassandraResourceProvider may
use the implementation directly to impose write and delete.

>
>
>> Take a deep breath, and you will see why I left this till last.
>>
>> I think we should provide path base access control, which inherits
>> from parent resources in the path. At every level there is a an
>> ordered list of access control entries each access control entry (ACE)
>> being either an allow entry or a deny entry. What is allowed or denied
>> is defined in a 32bit bitmap with each bit representing 1 permission,
>> so we can have upto 32 permissions. Each ACE specifies a single
>> principal. So an ACL consists of a ordered list of ACE's each one
>> bound to a principal.
>>
>> A user has a set of principals, so to resolve the ACL at any one path
>> for a user the global ACL is filtered to contain only the ACE's with
>> principals that the user has.
>>
>> Computing a final access control bitmap for a user at a location
>> requires ordered processing of all the ACEs relevant to the user at
>> the current path and then all ancestors.
>>
>> The pseudo algorithm to calculate the a grant bitmap and a deny bitmap
>> at any level is:
>>
>> function getCurrentLevelBitmaps(currentPath):
>>   int grants = 0;
>>   int denies = 0;
>>   for all ACEs in the ACL at the currentPath:
>> if the user has the principal of the current ACE:
>>   int toGrant = 0;
>>   int toDeny = 0;
>>   if the ACE is a grant:
>> toGrant = the ACE bitmap;
>>   else:
>> toDeny = the ACE bitmap;
>>   toGrant = toGrant & ~denies;
>>   toDeny = toDeny & ~grants;
>>   grants = grants | toGrant;
>>   denied = denies | toDenies;
>>   return (grants, denies);
>>
>
> - Can you please tell me how to calculate the ACE bitmap ?

That is just the 32bit integer stored in the cassandra column
representing the grant or deny for the principal

eg
Cassandra rowID : base64(sha1(/content/cassandra/foo/bar ))
Columns: 0_everyone_allow : 0x01, 1_admin_allow : 0x07

Allows everyone read and admin everything at the path /cassandra

> - Also I will be more clear if you can provide a sample value for the input
> and output of this function ? i.e When currentPath=
> /content/cassandra/foo/bar  it returns grants=? denies=? some actual values
> just for my understanding.

Using the above for a random user (ie has the everyone principal):
grants = 0x01
denies - 0x0

For the following values
Cassandra rowID : base64(sha1(/content/cassandra/foo/bar ))
Columns: 0_everyone_allow : 0x01, 1_admin_allow : 0x07, 2_ieb_deny : 0x01

results in
dishara : grants = 0x01, denies = 0x00
ieb : grants = 0x00, denies = 0x01
admin: grants = 0x07, denies = 0x00



>
>
>> To combine what is granted at the child level with what is granted at
>> a parent level we need to mask the parent level with the deny at the
>> child level.
>>
>> eg
>>  toGrant = grantedAtParent & ~denies;
>>  toDeny = deniedAtParent & ~grants;
>>  grants = grants | toGrant;
>>  denied = denies | toDenies;
>>
>> The simplest way of achieving this is to use recursion again in pseudo
>> code:
>>
>>function buildAtLevel():
>> if not root level:
>>  (grantedAtParent, deniedAtParent) =
>> buildAtLevel(getParentLevel(currentLevel));
>> (grants, denies) = getCurrentLevelBitmaps(currentLevel);
>> toGrant = grantedAtParent & ~denies;
>>toDeny = deniedAtParent & ~grants;
>>grants = grants | toGrant;
>>denied = denies | toDenies;
>>return (grants, denied);
>>
>>
>> There are some optimisations you can apply here, and there are plenty
>> of opportunities to cache intermediate bitmaps in memory. Just caching
>> the ACL reduces resolution to bitwise operations.
>>
>> Principals
>> 
>> Initially keep it simple.
>>
>> read = 0x01
>> write = 0x02
>> delete = 0x04
>>
>> Storage of ACLs.
>> 

Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #263

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.7 #263

[Apache Jenkins Server]

See 

[jira] [Updated] (SLING-2998) SlingAuthenticator fails because of pathInfo being null

[Oliver Lietz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Lietz updated SLING-2998:


Attachment: SLING-2998.2013-09-12.patch

improved patch
- concatenate servlet path and path info as their values are 
configuration/container dependent
- remove LoginServlet.SERVLET_PATH.equals(pathInfo) check as paths of 
LoginServlet and LogoutServlet are added to PathBasedHolderCache

> SlingAuthenticator fails because of pathInfo being null
> ---
>
> Key: SLING-2998
> URL: https://issues.apache.org/jira/browse/SLING-2998
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.1.2
> Environment: Sling, CQ
>Reporter: Oliver Lietz
>  Labels: security
> Attachments: SLING-2998.2013-09-12.patch, SLING-2998.patch
>
>
> - HttpServletRequest#getPathInfo():String returns null, use 
> HttpServletRequest#getServletPath():String instead
> - path should never be changed to /, instead return anonymous 
> credentials/false
> http://mail-archives.apache.org/mod_mbox/sling-users/201308.mbox/%3c201308021338.32243.apa...@oliverlietz.de%3e

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #1887

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.6 #1887

[Apache Jenkins Server]

See 

[jira] [Resolved] (SLING-3056) [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-3056.


Resolution: Fixed

m2e-feature and eclipse-m2e-ui plugin added as a separation for this

> [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse
> -
>
> Key: SLING-3056
> URL: https://issues.apache.org/jira/browse/SLING-3056
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> At the moment slingclipse contains extensions which require m2eclipse plugin 
> to be installed as a hard-dependency from slingclipse. These extensions 
> should, as a minimum, be separated from the remaining extensions, such that 
> the user can choose to install them or not. Technically, the separation will 
> be bundled into a separate feature

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: [GSoC2013] Access Control for Cassandra ResourceProvider

[Mike Müller]

> From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian Boston
> 
> Hi Mike,
> Thanks for the pointer.
> 
> On 12 September 2013 14:58, Mike Müller  wrote:
> > Hi
> >
> > The common way to solve such an access control for a provider like
> > the Cassandra resource provider is the new ResourceAccessSecurity
> > service. This is implemented in the bundle resourceaccesssecurity
> > (at this time only read rights will be checked).
> 
> Incidentally, how will other rights be enforced ?
> the update pattern is resource.adaptTo(ModifiableValueMap.class)
> 
> would the adapter factory check that the current user has write access
> to the resource before they can get their hands on a
> ModifiableValueMap ?

Yes, the resource will be wrapped to enforce the rights and the 
ModifiableValueMap as well...
But as I said by now only read rights are enforced. The Cassandra
resource provider is a very good example of a use case for this 
service.

Best regards
mike

[jira] [Created] (SLING-3056) [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse

[Stefan Egli (JIRA)]

Stefan Egli created SLING-3056:
--

 Summary: [Tooling] Separate m2eclipse dependent extensions from 
others, in slingclipse
 Key: SLING-3056
 URL: https://issues.apache.org/jira/browse/SLING-3056
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Stefan Egli
Assignee: Stefan Egli


At the moment slingclipse contains extensions which require m2eclipse plugin to 
be installed as a hard-dependency from slingclipse. These extensions should, as 
a minimum, be separated from the remaining extensions, such that the user can 
choose to install them or not. Technically, the separation will be bundled into 
a separate feature

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SLING-3056) [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse

[Stefan Egli (JIRA)]

Stefan Egli created SLING-3056:
--

 Summary: [Tooling] Separate m2eclipse dependent extensions from 
others, in slingclipse
 Key: SLING-3056
 URL: https://issues.apache.org/jira/browse/SLING-3056
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Affects Versions: Sling Eclipse IDE 1.0.0
Reporter: Stefan Egli
Assignee: Stefan Egli


At the moment slingclipse contains extensions which require m2eclipse plugin to 
be installed as a hard-dependency from slingclipse. These extensions should, as 
a minimum, be separated from the remaining extensions, such that the user can 
choose to install them or not. Technically, the separation will be bundled into 
a separate feature

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: [GSoC2013] Access Control for Cassandra ResourceProvider

[Mike Müller]

Hi

The common way to solve such an access control for a provider like
the Cassandra resource provider is the new ResourceAccessSecurity
service. This is implemented in the bundle resourceaccesssecurity 
(at this time only read rights will be checked). All you have to do is to 
implement the SPI ResourceAccessGate for the Cassandra provider
and set the provider.useResourceAccessSecurity property to true
for your ResourceProvider.
By time resourceaccesssecurity will also implement create, modify 
And delete rights.

Best regards
mike

> -Original Message-
> From: Dishara Wijewardana [mailto:ddwijeward...@gmail.com]
> Sent: Thursday, September 12, 2013 2:25 PM
> To: dev@sling.apache.org
> Subject: Re: [GSoC2013] Access Control for Cassandra ResourceProvider
> 
> Hi Ian
> 
> 
> On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston  wrote:
> 
> > Hi Dishara,
> > To make the Cassandra Resource Provider really useful I think we need
> > to add access control. I think the best way of doing this is to borrow
> > some concepts from Jackrabbit access control.
> >
> >
> The following algorithms, and etc does sling already have any
> implementation of it. If so I can reuse them. Since sling has few providers
> I believe they probably have some common interface.
> 
> 
> > Take a deep breath, and you will see why I left this till last.
> >
> > I think we should provide path base access control, which inherits
> > from parent resources in the path. At every level there is a an
> > ordered list of access control entries each access control entry (ACE)
> > being either an allow entry or a deny entry. What is allowed or denied
> > is defined in a 32bit bitmap with each bit representing 1 permission,
> > so we can have upto 32 permissions. Each ACE specifies a single
> > principal. So an ACL consists of a ordered list of ACE's each one
> > bound to a principal.
> >
> > A user has a set of principals, so to resolve the ACL at any one path
> > for a user the global ACL is filtered to contain only the ACE's with
> > principals that the user has.
> >
> > Computing a final access control bitmap for a user at a location
> > requires ordered processing of all the ACEs relevant to the user at
> > the current path and then all ancestors.
> >
> > The pseudo algorithm to calculate the a grant bitmap and a deny bitmap
> > at any level is:
> >
> > function getCurrentLevelBitmaps(currentPath):
> >   int grants = 0;
> >   int denies = 0;
> >   for all ACEs in the ACL at the currentPath:
> > if the user has the principal of the current ACE:
> >   int toGrant = 0;
> >   int toDeny = 0;
> >   if the ACE is a grant:
> > toGrant = the ACE bitmap;
> >   else:
> > toDeny = the ACE bitmap;
> >   toGrant = toGrant & ~denies;
> >   toDeny = toDeny & ~grants;
> >   grants = grants | toGrant;
> >   denied = denies | toDenies;
> >   return (grants, denies);
> >
> 
> - Can you please tell me how to calculate the ACE bitmap ?
> - Also I will be more clear if you can provide a sample value for the input
> and output of this function ? i.e When currentPath=
> /content/cassandra/foo/bar  it returns grants=? denies=? some actual values
> just for my understanding.
> 
> 
> > To combine what is granted at the child level with what is granted at
> > a parent level we need to mask the parent level with the deny at the
> > child level.
> >
> > eg
> >  toGrant = grantedAtParent & ~denies;
> >  toDeny = deniedAtParent & ~grants;
> >  grants = grants | toGrant;
> >  denied = denies | toDenies;
> >
> > The simplest way of achieving this is to use recursion again in pseudo
> > code:
> >
> >function buildAtLevel():
> > if not root level:
> >  (grantedAtParent, deniedAtParent) =
> > buildAtLevel(getParentLevel(currentLevel));
> > (grants, denies) = getCurrentLevelBitmaps(currentLevel);
> > toGrant = grantedAtParent & ~denies;
> >toDeny = deniedAtParent & ~grants;
> >grants = grants | toGrant;
> >denied = denies | toDenies;
> >return (grants, denied);
> >
> >
> > There are some optimisations you can apply here, and there are plenty
> > of opportunities to cache intermediate bitmaps in memory. Just caching
> > the ACL reduces resolution to bitwise operations.
> >
> > Principals
> > 
> > Initially keep it simple.
> >
> > read = 0x01
> > write = 0x02
> > delete = 0x04
> >
> > Storage of ACLs.
> > -
> > I suggest you store ACLs in their own Column Family, where the rowID is
> > base64(sha1(path)) or whatever path -> rowid encoding you have currently.
> >
> > IIRC Cassandra columns come out in the natural order of Strings
> > __ and the value is the bitmap of
> > permissions.
> >
> > - If I understand you

Re: [GSoC2013] Access Control for Cassandra ResourceProvider

[Dishara Wijewardana]

Hi Ian


On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston  wrote:

> Hi Dishara,
> To make the Cassandra Resource Provider really useful I think we need
> to add access control. I think the best way of doing this is to borrow
> some concepts from Jackrabbit access control.
>
>
The following algorithms, and etc does sling already have any
implementation of it. If so I can reuse them. Since sling has few providers
I believe they probably have some common interface.


> Take a deep breath, and you will see why I left this till last.
>
> I think we should provide path base access control, which inherits
> from parent resources in the path. At every level there is a an
> ordered list of access control entries each access control entry (ACE)
> being either an allow entry or a deny entry. What is allowed or denied
> is defined in a 32bit bitmap with each bit representing 1 permission,
> so we can have upto 32 permissions. Each ACE specifies a single
> principal. So an ACL consists of a ordered list of ACE's each one
> bound to a principal.
>
> A user has a set of principals, so to resolve the ACL at any one path
> for a user the global ACL is filtered to contain only the ACE's with
> principals that the user has.
>
> Computing a final access control bitmap for a user at a location
> requires ordered processing of all the ACEs relevant to the user at
> the current path and then all ancestors.
>
> The pseudo algorithm to calculate the a grant bitmap and a deny bitmap
> at any level is:
>
> function getCurrentLevelBitmaps(currentPath):
>   int grants = 0;
>   int denies = 0;
>   for all ACEs in the ACL at the currentPath:
> if the user has the principal of the current ACE:
>   int toGrant = 0;
>   int toDeny = 0;
>   if the ACE is a grant:
> toGrant = the ACE bitmap;
>   else:
> toDeny = the ACE bitmap;
>   toGrant = toGrant & ~denies;
>   toDeny = toDeny & ~grants;
>   grants = grants | toGrant;
>   denied = denies | toDenies;
>   return (grants, denies);
>

- Can you please tell me how to calculate the ACE bitmap ?
- Also I will be more clear if you can provide a sample value for the input
and output of this function ? i.e When currentPath=
/content/cassandra/foo/bar  it returns grants=? denies=? some actual values
just for my understanding.


> To combine what is granted at the child level with what is granted at
> a parent level we need to mask the parent level with the deny at the
> child level.
>
> eg
>  toGrant = grantedAtParent & ~denies;
>  toDeny = deniedAtParent & ~grants;
>  grants = grants | toGrant;
>  denied = denies | toDenies;
>
> The simplest way of achieving this is to use recursion again in pseudo
> code:
>
>function buildAtLevel():
> if not root level:
>  (grantedAtParent, deniedAtParent) =
> buildAtLevel(getParentLevel(currentLevel));
> (grants, denies) = getCurrentLevelBitmaps(currentLevel);
> toGrant = grantedAtParent & ~denies;
>toDeny = deniedAtParent & ~grants;
>grants = grants | toGrant;
>denied = denies | toDenies;
>return (grants, denied);
>
>
> There are some optimisations you can apply here, and there are plenty
> of opportunities to cache intermediate bitmaps in memory. Just caching
> the ACL reduces resolution to bitwise operations.
>
> Principals
> 
> Initially keep it simple.
>
> read = 0x01
> write = 0x02
> delete = 0x04
>
> Storage of ACLs.
> -
> I suggest you store ACLs in their own Column Family, where the rowID is
> base64(sha1(path)) or whatever path -> rowid encoding you have currently.
>
> IIRC Cassandra columns come out in the natural order of Strings
> __ and the value is the bitmap of
> permissions.
>
> - If I understand you correctly is   __ is
one ACE ? If per row there can be a ACL, there should be one additional
column by default called "ACL" and it will have a comma separated string
which are set of ACEs. Correct me if I am wrong.
- Who stores these ACEs ? any API?
- i.e  is a auto increment number we have to do a additional read
before storing ACE to check what is the last number for .

Where  is 000 to 999 ( I really doubt that a single ACL will
> have 1000 ACEs ever)
>
> Once you have this working, we can wire it into the ResourceProvider
> or another Sling API.
>
> Does that make sense ?
> Ian
>



-- 
Thanks
/Dishara

Re: Dynamically create and register OSGi services from configurations

[Tommaso Teofili]

On 12/set/2013, at 08:35, Felix Meschberger wrote:

> Hi
> 
> Am 11.09.2013 um 15:36 schrieb Tommaso Teofili:
> 
>> Thanks a lot Chetan, that helps a lot!
>> 
>> In the mentioned link it seems both ConfigurationFactory and 
>> ManagedServiceFactory could be used for that purpose, do you know if there 
>> is any difference / advantage / disadvantage of using one instead of the 
>> other? 
> 
> I think you are mixing concepts ;-)
> 
> The "configurationFactory" attribute to the @Component annotation is 
> information to the Apache Felix SCR plugin on how to generate the Metatype 
> descriptor (to use the component name as the factoryPID instead of the 
> service PID) -- as such this has nothing to do with the core problem but is 
> used to be able to describe configuration for tools such as the Web Console.
> 
> The mechanism actually used is so-called factory configuration. This is 
> achieved in conjunction with the OSGi Installer when your configuration nodes 
> have specific names of the form -, e.g. 
> "com.adobe.granite.monitoring.impl.ScriptConfigImpl-cpu".
> 
> This creates factory configurations and Declarative services will create an 
> instance for each configuration instance.

thanks Felix for clarifying, I'll let you know how it goes.

Regards,
Tommaso

> 
> Regards
> Felix
> 
>> 
>> Regards,
>> Tommaso
>> 
>> On 11/set/2013, at 11:53, Chetan Mehrotra wrote:
>> 
>>> You can use Component based on ConfigurationFactory. Have a look at
>>> [1] for one such example
>>> 
>>> [1] http://stackoverflow.com/a/15872131/1035417
>>> Chetan Mehrotra
>>> 
>>> 
>>> On Wed, Sep 11, 2013 at 3:05 PM, Tommaso Teofili  wrote:
 Hi all,
 
 that's probably a trivial question but I'm looking for the best practice 
 to create and register OSGi Services from configurations.
 Here's an example scenario:
 - I have an interface FooBar
 - I have an implementation DefaultFooBarImpl
 - I want to be able to specify a node like:
 {
  "jcr:primaryType" : "sling:OsgiConfig",
  "name" : "foo"
  "property-one" : "some-value",
  "property-two" : "another-value",
 }
 - and consequently I'd like a new instance of DefaultFooBarImpl to be 
 created and registered as a Service (of course implementing FooBar)
 - then if a new configuration node is added:
 {
  "jcr:primaryType" : "sling:OsgiConfig",
  "name" : "bar"
  "property-one" : "some-other-value",
  "property-two" : "yet-another-value",
 }
 - another instance of DefaultFooBarImpl is created and registered as a 
 Service.
 
 From my basic understanding (which may be obviously completely wrong) it 
 seems to me that the best fit for my use case would be using 
 ManagedServices [1] but I'm not too sure I should do that to handle 
 multiple instances.
 
 Thanks in advance and have a nice day,
 Tommaso
 
 [1] : 
 http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ManagedService.html
 
 
>> 
> 

[GSoC2013] Access Control for Cassandra ResourceProvider

[Ian Boston]

Hi Dishara,
To make the Cassandra Resource Provider really useful I think we need
to add access control. I think the best way of doing this is to borrow
some concepts from Jackrabbit access control.

Take a deep breath, and you will see why I left this till last.

I think we should provide path base access control, which inherits
from parent resources in the path. At every level there is a an
ordered list of access control entries each access control entry (ACE)
being either an allow entry or a deny entry. What is allowed or denied
is defined in a 32bit bitmap with each bit representing 1 permission,
so we can have upto 32 permissions. Each ACE specifies a single
principal. So an ACL consists of a ordered list of ACE's each one
bound to a principal.

A user has a set of principals, so to resolve the ACL at any one path
for a user the global ACL is filtered to contain only the ACE's with
principals that the user has.

Computing a final access control bitmap for a user at a location
requires ordered processing of all the ACEs relevant to the user at
the current path and then all ancestors.

The pseudo algorithm to calculate the a grant bitmap and a deny bitmap
at any level is:

function getCurrentLevelBitmaps(currentPath):
  int grants = 0;
  int denies = 0;
  for all ACEs in the ACL at the currentPath:
if the user has the principal of the current ACE:
  int toGrant = 0;
  int toDeny = 0;
  if the ACE is a grant:
toGrant = the ACE bitmap;
  else:
toDeny = the ACE bitmap;
  toGrant = toGrant & ~denies;
  toDeny = toDeny & ~grants;
  grants = grants | toGrant;
  denied = denies | toDenies;
  return (grants, denies);

To combine what is granted at the child level with what is granted at
a parent level we need to mask the parent level with the deny at the
child level.

eg
 toGrant = grantedAtParent & ~denies;
 toDeny = deniedAtParent & ~grants;
 grants = grants | toGrant;
 denied = denies | toDenies;

The simplest way of achieving this is to use recursion again in pseudo code:

   function buildAtLevel():
if not root level:
 (grantedAtParent, deniedAtParent) =
buildAtLevel(getParentLevel(currentLevel));
(grants, denies) = getCurrentLevelBitmaps(currentLevel);
toGrant = grantedAtParent & ~denies;
   toDeny = deniedAtParent & ~grants;
   grants = grants | toGrant;
   denied = denies | toDenies;
   return (grants, denied);


There are some optimisations you can apply here, and there are plenty
of opportunities to cache intermediate bitmaps in memory. Just caching
the ACL reduces resolution to bitwise operations.

Principals

Initially keep it simple.

read = 0x01
write = 0x02
delete = 0x04

Storage of ACLs.
-
I suggest you store ACLs in their own Column Family, where the rowID is
base64(sha1(path)) or whatever path -> rowid encoding you have currently.

IIRC Cassandra columns come out in the natural order of Strings
__ and the value is the bitmap of permissions.

Where  is 000 to 999 ( I really doubt that a single ACL will
have 1000 ACEs ever)

Once you have this working, we can wire it into the ResourceProvider
or another Sling API.

Does that make sense ?
Ian

Re: [Cassandra Resource] Create Update Sling Resource

[Ian Boston]

Hi,
>From the results published at [1].
Reversing the order shows up that the create time is quite variable
and probably not a function of the number of nodes within a
collection, but probably a function the activity and buffering within
the Cassandra layer.

Reverse the order and the first 200 items written will have the lowest
latency. Delete shows no difference in latency between 1K and 100M
child nodes.

That result is very encouraging, it means that performance is related
the IO speed of the disks underneath Cassandra and not a function of
the volume of data within Cassandra or the number of items within a
collection.

I think we have enough information, next is to implement access
control. I'll start a new thread for that.

Create
Add 1 child node to a collection of 100M child nodes takes 26ms
Add 1 child node to a collection of 10M child nodes takes 135ms
Add 1 child node to a collection of 1M child nodes takes 109ms
Add 1 child node to a collection of 100K child nodes takes 259ms
Add 1 child node to a collection of 10K child nodes takes 225ms
Add 1 child node to a collection of 1K child nodes takes 101ms

Update
Update 1 child node to a collection of 100M child nodes takes 44ms
Update 1 child node to a collection of 10M child nodes takes 84ms
Update 1 child node to a collection of 1M child nodes takes 258ms
Update 1 child node to a collection of 100K child nodes takes 116ms
Update 1 child node to a collection of 10K child nodes takes 231ms
Update 1 child node to a collection of 1K child nodes takes 113ms

Delete
Delete 1 child node to a collection of 100M child nodes takes 17ms
Delete 1 child node to a collection of 10M child nodes takes 11ms
Delete 1 child node to a collection of 1M child nodes takes 7ms
Delete 1 child node to a collection of 100K child nodes takes 7ms
Delete 1 child node to a collection of 10K child nodes takes 6ms
Delete 1 child node to a collection of 1K child nodes takes 7ms

On 12 September 2013 05:06, Dishara Wijewardana  wrote:
> Hi Ian,
> Once you look at the results, let me know whether you want new tests run
> results. Also please advice how to proceed further.
>
>
> On Wed, Sep 11, 2013 at 7:59 PM, Dishara Wijewardana <
> ddwijeward...@gmail.com> wrote:
>
>> Hi Ian,
>> I attached the results.zip file to the JIRA which has the latest results
>> as your expectation. I added new set of nodes in reverse order "F", "E"
>> .."A".
>> But here I came across in a issue (which I didn't came up last time, may
>> be due to my heap size), that hector fails to execute batches > around
>> 300-500.. So in my case batch size is 600. I googled for the issue
>> (me.prettyprint.hector.api.exceptions.HectorException: All host pools
>> marked down. Retry burden pushed out to client) and the solution was reduce
>> the batch size. Hence I ran the test for each node separately. Hence In new
>> results zip file each node has its own report file. I categorized them in
>> two 3 main folders so that you can easily locate the results. i.,e folders
>> "_create", "_update" , "_delete"  ..
>>
>>
>>
>>
>>
>> On Wed, Sep 11, 2013 at 1:58 PM, Ian Boston  wrote:
>>
>>> Hi,
>>> Could you re-run the tests for create in the reverse order, largest
>>> collection first.
>>>
>>> The reason for this is in the detail of the tests adding resources to
>>> collection E (10M child nodes) is flat until half way through and then
>>> starts to rise which makes me thing there might be something else
>>> going on on the machine of the create mechanism. I would like to rule
>>> out that Cassandra is caching writes and the speed of update bears no
>>> correlation to collection size, but is a function of sustained load. I
>>> would also like to rule out any possibility that another OS level
>>> process started to hog resources in the latter part of your tests.
>>>
>>> The results do look comparatively flat all the way up 100M items in a
>>> collection.
>>>
>>> Once we have done this we can move on to providing access control, on
>>> items.
>>>
>>> Best Regards
>>> Ian
>>>
>>>
>>>
>>> On 11 September 2013 03:37, Dishara Wijewardana 
>>> wrote:
>>> > Hi Ian,
>>> > Sorry the delay, I found my self some battery problems with my laptop. I
>>> > believe this is what you asked for. Here I added new 100 collections i.e
>>> > 1a,3a,5a etc in each old collections and did CUD. Please advice what I
>>> > should do next.
>>> >
>>> > CREATE
>>> > [RESULT] Average Latency Under Node A(1K)   = 11 (ms)
>>> > [RESULT] Average Latency Under Node B(10K)  = 9 (ms)
>>> > [RESULT] Average Latency Under Node C(100K) = 13 (ms)
>>> > [RESULT] Average Latency Under Node D(1M)   = 23 (ms)
>>> > [RESULT] Average Latency Under Node E(10M)  = 110 (ms)
>>> > [RESULT] Average Latency Under Node F(100M) = 306 (ms)
>>> > [FIRST RUN] #TOTAL CALLS = 600 Total Average Latency = 79 (ms)
>>> >
>>> > UPDATE
>>> > [RESULT] Average Latency Under Node A(1K)   = 9 (ms)
>>> > [RESULT] Average Latency Under Node B(10K)  = 8 (ms)
>>> > [RESULT] Average Latency Under Node C