date:20130418

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

2013-04-18 Thread BJ Hargrave

Can you please provide more detail on the issue? What do you mean by 
"cloning"? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2013/04/17 18:23
Subject:[equinox-dev] PermissionInfoCollection issues with perms 
cloning
Sent by:equinox-dev-boun...@eclipse.org



Hello All,

The current implementation of PermissionInfoCollection uses a rather odd 
method of cloning permissions which breaks our implementation.

Would anyone object to a new cloning technique which relies purely on 
serialization (which is a required interface of permission impls)?

I'll provide an impl unless someone has a problem with changing the 
current mechanism.

Thoughts?

-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

2013-04-18 Thread Raymond Auge

Hey guys, thanks for responding.

Forgive me for using the work "clone" (however, it really should be a clone
in my mind, the base class should have implemented Cloneable in addition to
Serializable).

Essentially the PermissionInfoCollection.addPermissions method attempts to
create a "copy" of the permission for the purpose adding to it's collection.

However, there is nowhere in the spec that states a permission impl must
have either a 0, 1 or 2 String constructor.

The only requirements are:

- they extend from the base Permission class
- thereby should be Serializable
- they be immutable.

So, the "reconstitution" if you will, using the 0, 1 or 2 String
constructor is really just working on assumption and accidentally works
because all of the implementations in standard java are just that simple.

I'm proposing a different "copy" mechanism that will work for any
implementation based on the assumption that they respect Serializable as
they must. I'm not quite sure what that looks like yet, but I have a few
ideas.

However, before going that far, I'm trying to see if I can make a change in
our code to avoid the need the change the equinox impl... but i'm
struggling with this.

Sincerely,
- Ray

On Thu, Apr 18, 2013 at 8:02 AM, BJ Hargrave  wrote:

> Can you please provide more detail on the issue? What do you mean by
> "cloning"?
> --
>
>  *BJ Hargrave*
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the *OSGi Alliance* *
> **hargr...@us.ibm.com* 
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
>
>
>
> From:Raymond Auge 
> To:Equinox development mailing list 
> Date:2013/04/17 18:23
> Subject:[equinox-dev] PermissionInfoCollection issues with perms
> cloning
> Sent by:equinox-dev-boun...@eclipse.org
> --
>
>
>
> Hello All,
>
> The current implementation of PermissionInfoCollection uses a rather odd
> method of cloning permissions which breaks our implementation.
>
> Would anyone object to a new cloning technique which relies purely on
> serialization (which is a required interface of permission impls)?
>
> I'll provide an impl unless someone has a problem with changing the
> current mechanism.
>
> Thoughts?
>
> -- *
> *
> *Raymond Augé* 
>  | Senior Software Architect | *Liferay,
> Inc.*   
>
> ---
> 24-25 October 2012 |* Liferay **Spain Symposium* | 
> *liferay.com/spain2012*
> 16 November 2012 |* Liferay **Italy Symposium* | 
> *liferay.com/italy2012*
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>

-- 
*Raymond Augé* 
 | Senior Software Architect | *Liferay,
Inc.*   

---

24-25 October 2012 |* Liferay **Spain Symposium* |
liferay.com/spain2012

16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

2013-04-18 Thread BJ Hargrave

I think it is pretty clear that permission classes must have a public 
constructor that is either empty or takes one or two strings. This is 
effectively required by the Java policy file grant format:

  grant {
  permission java.io.FilePermission "C:\\users\\cathy\\foo.bat", 
"read";
  };

and by the OSGi spec:

permissions ::= ( ’(’ qname (quoted-string quoted-string?)? ’)’ )+

If your permission classes do not conform to this convention, how do you 
create PermissionInfos for them? (Of course we are discussing 
PermissionInfoCollection which maps PermissionInfos into a 
PermissionCollection.) 

You seem to be proposing something rather large which is a replacement of 
the PermissionInfo encoded format [1] which is the serialized form of 
permissions in the OSGi spec.

What do the constructors look like on your permissions?

[1] 
http://www.osgi.org/javadoc/r5/core/org/osgi/service/permissionadmin/PermissionInfo.html#getEncoded%28%29

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2013/04/18 11:23
Subject:Re: [equinox-dev] PermissionInfoCollection issues with 
perms cloning
Sent by:equinox-dev-boun...@eclipse.org



Hey guys, thanks for responding.

Forgive me for using the work "clone" (however, it really should be a 
clone in my mind, the base class should have implemented Cloneable in 
addition to Serializable).

Essentially the PermissionInfoCollection.addPermissions method attempts to 
create a "copy" of the permission for the purpose adding to it's 
collection.

However, there is nowhere in the spec that states a permission impl must 
have either a 0, 1 or 2 String constructor. 

The only requirements are:

- they extend from the base Permission class
- thereby should be Serializable
- they be immutable.

So, the "reconstitution" if you will, using the 0, 1 or 2 String 
constructor is really just working on assumption and accidentally works 
because all of the implementations in standard java are just that simple.

I'm proposing a different "copy" mechanism that will work for any 
implementation based on the assumption that they respect Serializable as 
they must. I'm not quite sure what that looks like yet, but I have a few 
ideas.

However, before going that far, I'm trying to see if I can make a change 
in our code to avoid the need the change the equinox impl... but i'm 
struggling with this.

Sincerely,
- Ray


On Thu, Apr 18, 2013 at 8:02 AM, BJ Hargrave  wrote:
Can you please provide more detail on the issue? What do you mean by 
"cloning"? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list  
Date:2013/04/17 18:23 
Subject:[equinox-dev] PermissionInfoCollection issues with perms 
cloning 
Sent by:equinox-dev-boun...@eclipse.org 



Hello All, 

The current implementation of PermissionInfoCollection uses a rather odd 
method of cloning permissions which breaks our implementation. 

Would anyone object to a new cloning technique which relies purely on 
serialization (which is a required interface of permission impls)? 

I'll provide an impl unless someone has a problem with changing the 
current mechanism. 

Thoughts? 

-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc.  
--- 
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012 
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

2013-04-18 Thread BJ Hargrave

> Essentially the PermissionInfoCollection.addPermissions method 
> attempts to create a "copy" of the permission for the purpose adding
> to it's collection.

Also, to be clear, there is no copying going on here. The code needs to 
construct a Permission object from the information in the PermissionInfo. 
The PermissionInfo contains the class name of the permission type with 0, 
1 or 2 String arguments for the constructor. This very much the same as 
would be done by the Policy object to create permissions based upon the 
grant information in the policy file.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

2013-04-18 Thread Raymond Auge

Ok, I stand corrected. After looking at the code for PolicyParser it seems
the 0, 1, 2 rule is indeed the case.

Other documentation seems to have implied that an arbitrary number of
constructor arguments were acceptable:

http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA

However, I guess each of these different policy files must have it's own
parser.

Sorry about my confusion.

- Ray

Thx


On Thu, Apr 18, 2013 at 12:05 PM, BJ Hargrave  wrote:

> > Essentially the PermissionInfoCollection.addPermissions method
> > attempts to create a "copy" of the permission for the purpose adding
> > to it's collection.
>
> Also, to be clear, there is no copying going on here. The code needs to
> construct a Permission object from the information in the PermissionInfo.
> The PermissionInfo contains the class name of the permission type with 0, 1
> or 2 String arguments for the constructor. This very much the same as would
> be done by the Policy object to create permissions based upon the grant
> information in the policy file.
> --
>
>  *BJ Hargrave*
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the *OSGi Alliance* *
> **hargr...@us.ibm.com* 
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>


-- 
*Raymond Augé* 
 | Senior Software Architect | *Liferay,
Inc.*   

---

24-25 October 2012 |* Liferay **Spain Symposium* |
liferay.com/spain2012

16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

2013-04-18 Thread Raymond Auge

PS: We were not loading our permissions from a standard policy file. Hence
how we ended up with what we have.


On Thu, Apr 18, 2013 at 12:26 PM, Raymond Auge wrote:

> Ok, I stand corrected. After looking at the code for PolicyParser it seems
> the 0, 1, 2 rule is indeed the case.
>
> Other documentation seems to have implied that an arbitrary number of
> constructor arguments were acceptable:
>
>
> http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA
>
> However, I guess each of these different policy files must have it's own
> parser.
>
> Sorry about my confusion.
>
> - Ray
>
> Thx
>
>
> On Thu, Apr 18, 2013 at 12:05 PM, BJ Hargrave  wrote:
>
>> > Essentially the PermissionInfoCollection.addPermissions method
>> > attempts to create a "copy" of the permission for the purpose adding
>> > to it's collection.
>>
>> Also, to be clear, there is no copying going on here. The code needs to
>> construct a Permission object from the information in the PermissionInfo.
>> The PermissionInfo contains the class name of the permission type with 0, 1
>> or 2 String arguments for the constructor. This very much the same as would
>> be done by the Policy object to create permissions based upon the grant
>> information in the policy file.
>> --
>>
>>  *BJ Hargrave*
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the *OSGi Alliance* *
>> **hargr...@us.ibm.com* 
>>
>> office: +1 386 848 1781
>> mobile: +1 386 848 3788
>>
>>
>> ___
>> equinox-dev mailing list
>> equinox-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
>
>
> --
> *Raymond Augé* 
>  | Senior Software Architect | *Liferay,
> Inc.*   
>
> ---
>
> 24-25 October 2012 |* Liferay **Spain Symposium* | 
> liferay.com/spain2012
>
> 16 November 2012 |* Liferay **Italy Symposium* | 
> liferay.com/italy2012
>
>


-- 
*Raymond Augé* 
 | Senior Software Architect | *Liferay,
Inc.*   

---

24-25 October 2012 |* Liferay **Spain Symposium* |
liferay.com/spain2012

16 November 2012 |* Liferay **Italy Symposium* |
liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

2013-04-18 Thread BJ Hargrave

Then you probably have your own way to populate your 
PermissionCollections. However in Equinox which supports the OSGi 
permission specifications, the way to populate the PermissionCollections 
is via PermissionInfos which require the "0,1,2" constructors. 

If you have special permissions that cannot have those sort of 
constructors, then you can't use the OSGi permissions specifications and 
will need to customize a framework implementation to use your own 
permission management model.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2013/04/18 12:29
Subject:Re: [equinox-dev] PermissionInfoCollection issues with 
perms cloning
Sent by:equinox-dev-boun...@eclipse.org



PS: We were not loading our permissions from a standard policy file. Hence 
how we ended up with what we have.


On Thu, Apr 18, 2013 at 12:26 PM, Raymond Auge  
wrote:
Ok, I stand corrected. After looking at the code for PolicyParser it seems 
the 0, 1, 2 rule is indeed the case.

Other documentation seems to have implied that an arbitrary number of 
constructor arguments were acceptable:

http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA

However, I guess each of these different policy files must have it's own 
parser.

Sorry about my confusion.

- Ray

Thx


On Thu, Apr 18, 2013 at 12:05 PM, BJ Hargrave  wrote:
> Essentially the PermissionInfoCollection.addPermissions method 
> attempts to create a "copy" of the permission for the purpose adding
> to it's collection. 

Also, to be clear, there is no copying going on here. The code needs to 
construct a Permission object from the information in the PermissionInfo. 
The PermissionInfo contains the class name of the permission type with 0, 
1 or 2 String arguments for the constructor. This very much the same as 
would be done by the Policy object to create permissions based upon the 
grant information in the policy file. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012




-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

7 matches

Site Navigation

Mail list logo

Footer information