You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2011/01/04 12:00:27 UTC

Broken links of website

Hi all,

I saw that Zoe has updated the website.

Regarding http://aries.apache.org the links on the left menu are broken, 
for instance:

Not Found
The requested URL /aries/community/mailinglists.html was not found on 
this server.
Apache/2.3.8 (Unix) mod_ssl/2.3.8 OpenSSL/1.0.0a Server at 
aries.apache.org Port 80

Regards
JB

RE: Java 2 security around field injection

Posted by Timothy Ward <ti...@apache.org>.
+1 from me as well.

It obviously stinks to require any blueprint bundle to have ReflectPermission to use the field injection schema (particularly for annotation based injection), but it would be unpleasant to allow any bundle to reflectively change classes from other bundles or the VM. I think this is a sensible middle ground.

Tim

----------------------------------------
> Subject: Re: Java 2 security around field injection
> From: not@apache.org
> Date: Tue, 4 Jan 2011 16:34:33 +0000
> To: dev@aries.apache.org
>
> Sounds reasonable to me.
>
> Alasdair Nottingham
>
> On 4 Jan 2011, at 16:09, Valentin Mahrwald  wrote:
>
> > Hi,
> >
> > in some external testing with the Apache Aries stack under Java 2 security I have found that the field injection that was introduced a while back does not work all that great.
> >
> > Currently, Blueprint uses the joint permissions of the Blueprint bundle and the Blueprint extender bundle to perform any kind of privileged actions like property injection, service retrieval and field injection.
> >
> > However, this permission scheme does not work that well with field injection because usually a Blueprint bundle would not need to (and probably should not) have ReflectPermission. Especially, if all that the field injection is used for is something relatively common like injecting a PersistenceContext ...
> >
> > So what I would like to implement is a scheme where we the restrictions are a bit more relaxed:
> > - field injection for fields in classes that reside in the Blueprint bundle itself is done with the permissions of the Blueprint extender
> > - all other field injections uses joint permissions as before
> >
> > That kind of scheme should allow a good majority of the use cases of field injection while hopefully not compromising security.
> >
> > What do people think? Are there better alternatives?
> >
> > Regards,
> >
> > Valentin
> >
> >
> > ---
> > Stack trace:
> >
> > java.security.AccessControlException: Access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
> > at java.security.AccessController.checkPermission(AccessController.java:108)
> > at java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
> > at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
> > at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
> > at org.apache.aries.blueprint.utils.ReflectionUtils$FieldPropertyDescriptor.internalSet(ReflectionUtils.java:379)
> > at org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor$2.run(ReflectionUtils.java:307)
> > at java.security.AccessController.doPrivileged(AccessController.java:288)
> > at org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:305)
> > at org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:810)
> > at org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:778)
> > at org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:759)
> > at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:725)
> > at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
> > at org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:60)
> > at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
> > at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)
> > at org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:198)
> > at org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:137)
> > at org.apache.aries.blueprint.container.ServiceRecipe.createRecipe(ServiceRecipe.java:368)
> > at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:276)
> > at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:246)
> > at org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:325)
> > at org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:430)

Re: Java 2 security around field injection

Posted by Alasdair Nottingham <no...@apache.org>.
Sounds reasonable to me.

Alasdair Nottingham

On 4 Jan 2011, at 16:09, Valentin Mahrwald <vm...@googlemail.com> wrote:

> Hi,
> 
> in some external testing with the Apache Aries stack under Java 2 security I have found that the field injection that was introduced a while back does not work all that great.
> 
> Currently, Blueprint uses the joint permissions of the Blueprint bundle and the Blueprint extender bundle to perform any kind of privileged actions like property injection, service retrieval and field injection.
> 
> However, this permission scheme does not work that well with field injection because usually a Blueprint bundle would not need to (and probably should not) have ReflectPermission. Especially, if all that the field injection is used for is something relatively common like injecting a PersistenceContext ...
> 
> So what I would like to implement is a scheme where we the restrictions are a bit more relaxed:
> - field injection for fields in classes that reside in the Blueprint bundle itself is done with the permissions of the Blueprint extender
> - all other field injections uses joint permissions as before
> 
> That kind of scheme should allow a good majority of the use cases of field injection while hopefully not compromising security.
> 
> What do people think? Are there better alternatives?
> 
> Regards,
> 
> Valentin
> 
> 
> ---
> Stack trace:
> 
> java.security.AccessControlException: Access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
> at java.security.AccessController.checkPermission(AccessController.java:108)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
> at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
> at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
> at org.apache.aries.blueprint.utils.ReflectionUtils$FieldPropertyDescriptor.internalSet(ReflectionUtils.java:379)
> at org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor$2.run(ReflectionUtils.java:307)
> at java.security.AccessController.doPrivileged(AccessController.java:288)
> at org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:305)
> at org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:810)
> at org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:778)
> at org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:759)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:725)
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
> at org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:60)
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:198)
> at org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:137)
> at org.apache.aries.blueprint.container.ServiceRecipe.createRecipe(ServiceRecipe.java:368)
> at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:276)
> at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:246)
> at org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:325)
> at org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:430)

Java 2 security around field injection

Posted by Valentin Mahrwald <vm...@googlemail.com>.
Hi,

in some external testing with the Apache Aries stack under Java 2 security I have found that the field injection that was introduced a while back does not work all that great.

Currently, Blueprint uses the joint permissions of the Blueprint bundle and the Blueprint extender bundle to perform any kind of privileged actions like property injection, service retrieval and field injection.

However, this permission scheme does not work that well with field injection because usually a Blueprint bundle would not need to (and probably should not) have ReflectPermission. Especially, if all that the field injection is used for is something relatively common like injecting a PersistenceContext ...

So what I would like to implement is a scheme where we the restrictions are a bit more relaxed:
- field injection for fields in classes that reside in the Blueprint bundle itself is done with the permissions of the Blueprint extender
- all other field injections uses joint permissions as before

That kind of scheme should allow a good majority of the use cases of field injection while hopefully not compromising security.

What do people think? Are there better alternatives?

Regards,

Valentin


---
Stack trace:

java.security.AccessControlException: Access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
at java.security.AccessController.checkPermission(AccessController.java:108)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
at org.apache.aries.blueprint.utils.ReflectionUtils$FieldPropertyDescriptor.internalSet(ReflectionUtils.java:379)
at org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor$2.run(ReflectionUtils.java:307)
at java.security.AccessController.doPrivileged(AccessController.java:288)
at org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:305)
at org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:810)
at org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:778)
at org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:759)
at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:725)
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
at org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:60)
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)
at org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:198)
at org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:137)
at org.apache.aries.blueprint.container.ServiceRecipe.createRecipe(ServiceRecipe.java:368)
at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:276)
at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:246)
at org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:325)
at org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:430)

Re: Broken links of website

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yeah, I saw the Jira :)

Thanks Zoe

Regards
JB

On 01/04/2011 12:57 PM, zoe slattery wrote:
> On 04/01/2011 11:00, Jean-Baptiste Onofré wrote:
>> Hi all,
>>
>> I saw that Zoe has updated the website.
>>
>> Regarding http://aries.apache.org the links on the left menu are
>> broken, for instance:
>>
>> Not Found
>> The requested URL /aries/community/mailinglists.html was not found on
>> this server.
>> Apache/2.3.8 (Unix) mod_ssl/2.3.8 OpenSSL/1.0.0a Server at
>> aries.apache.org Port 80
>>
>> Regards
>> JB
>>
> Hi Jean-Baptiste, thanks for spotting that. I'm just in the process of
> fixing the site after graduation (see
> https://issues.apache.org/jira/browse/ARIES-529), I expect many links to
> be broken because the site address has moved before the content was
> updated. Hope this will be complete by the end of today.
>
> Zoe

Re: Broken links of website

Posted by zoe slattery <zo...@gmail.com>.
On 04/01/2011 11:00, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I saw that Zoe has updated the website.
>
> Regarding http://aries.apache.org the links on the left menu are 
> broken, for instance:
>
> Not Found
> The requested URL /aries/community/mailinglists.html was not found on 
> this server.
> Apache/2.3.8 (Unix) mod_ssl/2.3.8 OpenSSL/1.0.0a Server at 
> aries.apache.org Port 80
>
> Regards
> JB
>
Hi Jean-Baptiste, thanks for spotting that. I'm just in the process of 
fixing the site after graduation (see 
https://issues.apache.org/jira/browse/ARIES-529),  I expect many links 
to be broken because the site address has moved before the content was 
updated. Hope this will be complete by the end of today.

Zoe