You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Sander de Groot <s....@jdi.nl> on 2010/07/09 13:08:52 UTC
Bundle permissions
Hi,
After some research about security in OSGi I've found that it is fairly
difficult to find examples of how permissions are set.
The following resources proofed to be usefull:
- http://www.mail-archive.com/users@felix.apache.org/msg05090.html
- http://www.osgi.org/download/r4v41/r4.core.pdf
-
http://felix.apache.org/site/presentations.data/Building%20Secure%20OSGi%20Applications%20Workshop.pdf
Each of the links above contain a lot of theory but nothing practical
really.
My goal is fairly simple: I have got multiple bundles of a specific
category (webapplications) each of these webapplications have their own
'home' directory. I want Felix to limit their file system access only to
this home directory and if necessary a few other specifically assigned
directories.
My question: how can I achieve this permission scheme?
Related questions:
* Is specifying permissions limited to specific boundaries? (like:
bundlename, should the bundle specify its own permissions, etc.)
* How can I discriminate different 'categories'/'types' of bundles
* What about signing the bundles? Is this necessary, how to and why?
Before I was used to create my own SecurityManager which would limit the
application programmatic. I don't mind using files or some other way but
I'd like to be in full control.
Is this possible and so yes can you point me (or provide me) some examples?
Regards,
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
and again, thank you so much. I could've searched for weeks without
finding this, haha.
I'm sorry for the rookie mistake, won't happen again ;-)
- we're all still laughing over here
On 07/13/2010 04:35 PM, Karl Pauls wrote:
> Well, you did grant java.lang.AllPermission which doesn't exist.
> Should be java.security.AllPermission no?
>
> :-)
>
> On Tue, Jul 13, 2010 at 4:31 PM, Sander de Groot<s....@jdi.nl> wrote:
>
>> Uh, right, how stupid of me.
>> But I think I know why I didn't include this property because I now get the
>> following exception:
>>
>> Exception in thread "main" java.security.AccessControlException: access
>> denied (java.util.PropertyPermission felix.system.properties read)
>> at
>> java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
>> at
>> java.security.AccessController.checkPermission(AccessController.java:546)
>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
>> at
>> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
>> at java.lang.System.getProperty(System.java:650)
>> at org.apache.felix.main.Main.loadSystemProperties(Main.java:363)
>> at org.apache.felix.main.Main.main(Main.java:229)
>>
>> I only added the property
>>
>> -Djava.security.manager
>>
>>
>> It now seems the system is not allowed to read the system properties? Which
>> is weird because I granted allpermission in all.policy (see below)
>>
>> On 07/13/2010 04:03 PM, Karl Pauls wrote:
>>
>>> I think you are missing to add a security manager try to add:
>>>
>>> -Djava.security.manager
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>
>>>
>>> On Tue, Jul 13, 2010 at 3:57 PM, Sander de Groot<s....@jdi.nl> wrote:
>>>
>>>
>>>> java -Dlogback.configurationFile=$(pwd)/conf/logback.xml
>>>> -Djava.security.policy=conf/all.policy -d64 -noverify
>>>> -javaagent:bin/jrebel.jar -Xdebug -Xnoagent
>>>> -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -Xms60m
>>>> -Xmx512m -server -Dfelix.config.properties=file:./conf/config.properties
>>>> -Djdi.webapps=$(pwd)/webapps
>>>> -Djdi.webapps.exploded=$(pwd)/webapps/exploded
>>>> -jar bin/felix.jar
>>>>
>>>> I was told to add the all.policy file. This shouldn't be the problem,
>>>> right?
>>>> I should probably test it without the all.policy file...
>>>>
>>>> all.policy:
>>>> grant {
>>>> permission java.lang.AllPermission;
>>>> };
>>>>
>>>>
>>>>
>>>> On 07/13/2010 03:33 PM, Richard S. Hall wrote:
>>>>
>>>>
>>>>> Out of curiosity, how are you launching the framework?
>>>>>
>>>>> -> richard
>>>>>
>>>>> On 7/13/10 8:40, Sander de Groot wrote:
>>>>>
>>>>>
>>>>>> After compiling the trunk, felix accepts the input.
>>>>>> But it still doesn't seem to work, I'm probably doing something wrong..
>>>>>>
>>>>>> security.policy:
>>>>>> DENY {
>>>>>> ( java.io.FilePermission "*" "*")
>>>>>> } "Deny all access to files"
>>>>>> DENY {
>>>>>> ( java.security.AllPermission "*" "*")
>>>>>> } "Deny everything"
>>>>>>
>>>>>> Running bundles (in this order):
>>>>>> START LEVEL 1
>>>>>> ID|State |Level|Name
>>>>>> 0|Active | 0|System Bundle (3.0.1)
>>>>>> 1|Active | 1|Logback Classic Module (0.9.24)
>>>>>> 2|Active | 1|Logback Core Module (0.9.24)
>>>>>> 3|Active | 1|Apache Felix Bundle Repository (1.6.2)
>>>>>> 4|Active | 1|Apache Felix Configuration Admin Service (1.2.4)
>>>>>> 5|Active | 1|Apache Felix EventAdmin (1.2.2)
>>>>>> 6|Active | 1|Apache Felix File Install (3.0.0)
>>>>>> 8|Resolved | 1|Apache Felix Security Provider (1.3.0.SNAPSHOT)
>>>>>> 9|Active | 1|Apache Felix Gogo Command (0.6.0)
>>>>>> 10|Active | 1|Apache Felix Gogo Runtime (0.6.0)
>>>>>> 11|Active | 1|Apache Felix Gogo Shell (0.6.0)
>>>>>> 12|Active | 1|Apache Felix Http Bundle (2.0.4)
>>>>>> 13|Active | 1|Apache Felix Log Service (1.0.0)
>>>>>> 14|Active | 1|Apache Felix Shell Service (1.4.2)
>>>>>> 15|Active | 1|Apache Felix Remote Shell (1.0.4)
>>>>>> 16|Active | 1|Apache Felix Web Management Console (3.1.0)
>>>>>> 17|Active | 1|Security Manager (0.0.1.init)
>>>>>> 18|Active | 1|slf4j-api (1.6.0)
>>>>>> 19|Active | 1|Webapplication1 (1.0.0.init)
>>>>>>
>>>>>> The security manager is the dedicated bundle copied exactly from
>>>>>>
>>>>>> http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example/org.foo.policy/src/org/foo/policy/Activator.java.
>>>>>> The security manager says it loads the file and I see that the features
>>>>>> are
>>>>>> loaded but the security.policy file still doesn't seem to work.
>>>>>>
>>>>>> Relevant code in webapplication 1:
>>>>>> private void localFile() {
>>>>>> FileWriter fw1 = null;
>>>>>> try {
>>>>>> fw1 = new FileWriter(new
>>>>>> File("/home/sander/Desktop/test.txt"));
>>>>>> fw1.write("Hello World!!!\n");
>>>>>> fw1.write(now("H:mm:ss:SSS"));
>>>>>> } catch ( Exception e ) {
>>>>>> System.err.println("Exception: ");
>>>>>> e.printStackTrace(System.err);
>>>>>> } finally {
>>>>>> try {
>>>>>> fw1.close();
>>>>>> } catch (Throwable e) {
>>>>>> e.printStackTrace(System.err);
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The file is written with the security.policy file in place.. If I try
>>>>>> to
>>>>>> modify a file owned by another user (no OS permissions) then as
>>>>>> expected
>>>>>> there is raised an exception.
>>>>>>
>>>>>> Could you tell me what's going wrong?
>>>>>>
>>>>>> Thanks in advance, your replies are appreciated greatly!
>>>>>>
>>>>>> On 07/12/2010 05:09 PM, Sander de Groot wrote:
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> For now, I'm using the example code provided in chapter 14. However
>>>>>>>>> there
>>>>>>>>> arises a (probably) small new problem. I think it's related to
>>>>>>>>> different
>>>>>>>>> Felix versions used be me and used in the book. (I don't know for
>>>>>>>>> sure, I'm
>>>>>>>>> using 3.0.1)
>>>>>>>>>
>>>>>>>>>
>>>>>>>> You need to use the latest framework.security provider trunk
>>>>>>>> (3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
>>>>>>>> about that - it should work with framework 3.0.1 so.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Hmm from the trunk. When can I expect a release? It does seem to work
>>>>>>> now, I'll test more extensively tomorrow.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> After some additional research I've found that the security
>>>>>>>>>>> features
>>>>>>>>>>> of
>>>>>>>>>>> Felix are not as mature as of Equinox.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Why not? It would be nice if you could give me some indication
>>>>>>>>>> what
>>>>>>>>>> your research did find that makes you say that...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I have to admit, the statements are a little outdated (2009).
>>>>>>>>> At the moment I don't have any references but if you insist I can
>>>>>>>>> look
>>>>>>>>> them
>>>>>>>>> up. But again it isn't that big of an issue because it seems to be
>>>>>>>>> working
>>>>>>>>> fine.
>>>>>>>>> One of the comments made was about the internal implementation, it
>>>>>>>>> was
>>>>>>>>> said
>>>>>>>>> that Felix did not check always the necessary permissions.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Ok, ic, that is outdated. We implement what needs to be implemented
>>>>>>>> by
>>>>>>>> the spec.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> It also seems that the security
>>>>>>>>>>> package provided at the felix download page won't start. Is this
>>>>>>>>>>> normal?
>>>>>>>>>>>
>>>>>>>>>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Yes, its an extension bundle (they don't get started).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Of course...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Sander/
>>>>>>>>> /
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> What you have to do is to create a dedicated bundle that will
>>>>>>>>>>>> play
>>>>>>>>>>>> the
>>>>>>>>>>>> role of the permission agent.
>>>>>>>>>>>>
>>>>>>>>>>>> Within this bundle :
>>>>>>>>>>>> - get the permission admin service reference
>>>>>>>>>>>> - get the permission list
>>>>>>>>>>>> - grant allpermission to the system bundle (bundle 0), other
>>>>>>>>>>>> Felix
>>>>>>>>>>>> bundles
>>>>>>>>>>>> may need allpermission
>>>>>>>>>>>> - grant allpermission to this permission agent bundle
>>>>>>>>>>>> - then grant the different permissions you need to other bundles
>>>>>>>>>>>> - commit the permission list to the permission table
>>>>>>>>>>>>
>>>>>>>>>>>> Then, each time a permission check occurs, the security layer
>>>>>>>>>>>> will
>>>>>>>>>>>> be
>>>>>>>>>>>> able
>>>>>>>>>>>> to determine whether each bundle providing each method on the
>>>>>>>>>>>> call
>>>>>>>>>>>> stack
>>>>>>>>>>>> has
>>>>>>>>>>>> been granted this particular permission.
>>>>>>>>>>>>
>>>>>>>>>>>> Actually, as the permission administration is provided as a
>>>>>>>>>>>> service, any
>>>>>>>>>>>> bundle having sufficient permissions can modify the permission
>>>>>>>>>>>> table at
>>>>>>>>>>>> any
>>>>>>>>>>>> time. So yes, you can therefore add/delete and commit new
>>>>>>>>>>>> permissions
>>>>>>>>>>>> when
>>>>>>>>>>>> catching some specific framework or service events.
>>>>>>>>>>>>
>>>>>>>>>>>> François
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sander de Groot wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Would it be possible to create a custom bundle which listens to
>>>>>>>>>>>>> other
>>>>>>>>>>>>> bundles' events and apply a specific permission scheme based on
>>>>>>>>>>>>> the for
>>>>>>>>>>>>> example bundlename/location or other properties? If so how can I
>>>>>>>>>>>>> enforce
>>>>>>>>>>>>> such a scheme on another bundle?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sander
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Karl Pauls <ka...@gmail.com>.
Well, you did grant java.lang.AllPermission which doesn't exist.
Should be java.security.AllPermission no?
:-)
On Tue, Jul 13, 2010 at 4:31 PM, Sander de Groot <s....@jdi.nl> wrote:
> Uh, right, how stupid of me.
> But I think I know why I didn't include this property because I now get the
> following exception:
>
> Exception in thread "main" java.security.AccessControlException: access
> denied (java.util.PropertyPermission felix.system.properties read)
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at
> java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
> at java.lang.System.getProperty(System.java:650)
> at org.apache.felix.main.Main.loadSystemProperties(Main.java:363)
> at org.apache.felix.main.Main.main(Main.java:229)
>
> I only added the property
>
> -Djava.security.manager
>
>
> It now seems the system is not allowed to read the system properties? Which
> is weird because I granted allpermission in all.policy (see below)
>
> On 07/13/2010 04:03 PM, Karl Pauls wrote:
>>
>> I think you are missing to add a security manager try to add:
>>
>> -Djava.security.manager
>>
>> regards,
>>
>> Karl
>>
>>
>>
>> On Tue, Jul 13, 2010 at 3:57 PM, Sander de Groot<s....@jdi.nl> wrote:
>>
>>>
>>> java -Dlogback.configurationFile=$(pwd)/conf/logback.xml
>>> -Djava.security.policy=conf/all.policy -d64 -noverify
>>> -javaagent:bin/jrebel.jar -Xdebug -Xnoagent
>>> -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -Xms60m
>>> -Xmx512m -server -Dfelix.config.properties=file:./conf/config.properties
>>> -Djdi.webapps=$(pwd)/webapps
>>> -Djdi.webapps.exploded=$(pwd)/webapps/exploded
>>> -jar bin/felix.jar
>>>
>>> I was told to add the all.policy file. This shouldn't be the problem,
>>> right?
>>> I should probably test it without the all.policy file...
>>>
>>> all.policy:
>>> grant {
>>> permission java.lang.AllPermission;
>>> };
>>>
>>>
>>>
>>> On 07/13/2010 03:33 PM, Richard S. Hall wrote:
>>>
>>>>
>>>> Out of curiosity, how are you launching the framework?
>>>>
>>>> -> richard
>>>>
>>>> On 7/13/10 8:40, Sander de Groot wrote:
>>>>
>>>>>
>>>>> After compiling the trunk, felix accepts the input.
>>>>> But it still doesn't seem to work, I'm probably doing something wrong..
>>>>>
>>>>> security.policy:
>>>>> DENY {
>>>>> ( java.io.FilePermission "*" "*")
>>>>> } "Deny all access to files"
>>>>> DENY {
>>>>> ( java.security.AllPermission "*" "*")
>>>>> } "Deny everything"
>>>>>
>>>>> Running bundles (in this order):
>>>>> START LEVEL 1
>>>>> ID|State |Level|Name
>>>>> 0|Active | 0|System Bundle (3.0.1)
>>>>> 1|Active | 1|Logback Classic Module (0.9.24)
>>>>> 2|Active | 1|Logback Core Module (0.9.24)
>>>>> 3|Active | 1|Apache Felix Bundle Repository (1.6.2)
>>>>> 4|Active | 1|Apache Felix Configuration Admin Service (1.2.4)
>>>>> 5|Active | 1|Apache Felix EventAdmin (1.2.2)
>>>>> 6|Active | 1|Apache Felix File Install (3.0.0)
>>>>> 8|Resolved | 1|Apache Felix Security Provider (1.3.0.SNAPSHOT)
>>>>> 9|Active | 1|Apache Felix Gogo Command (0.6.0)
>>>>> 10|Active | 1|Apache Felix Gogo Runtime (0.6.0)
>>>>> 11|Active | 1|Apache Felix Gogo Shell (0.6.0)
>>>>> 12|Active | 1|Apache Felix Http Bundle (2.0.4)
>>>>> 13|Active | 1|Apache Felix Log Service (1.0.0)
>>>>> 14|Active | 1|Apache Felix Shell Service (1.4.2)
>>>>> 15|Active | 1|Apache Felix Remote Shell (1.0.4)
>>>>> 16|Active | 1|Apache Felix Web Management Console (3.1.0)
>>>>> 17|Active | 1|Security Manager (0.0.1.init)
>>>>> 18|Active | 1|slf4j-api (1.6.0)
>>>>> 19|Active | 1|Webapplication1 (1.0.0.init)
>>>>>
>>>>> The security manager is the dedicated bundle copied exactly from
>>>>>
>>>>> http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example/org.foo.policy/src/org/foo/policy/Activator.java.
>>>>> The security manager says it loads the file and I see that the features
>>>>> are
>>>>> loaded but the security.policy file still doesn't seem to work.
>>>>>
>>>>> Relevant code in webapplication 1:
>>>>> private void localFile() {
>>>>> FileWriter fw1 = null;
>>>>> try {
>>>>> fw1 = new FileWriter(new
>>>>> File("/home/sander/Desktop/test.txt"));
>>>>> fw1.write("Hello World!!!\n");
>>>>> fw1.write(now("H:mm:ss:SSS"));
>>>>> } catch ( Exception e ) {
>>>>> System.err.println("Exception: ");
>>>>> e.printStackTrace(System.err);
>>>>> } finally {
>>>>> try {
>>>>> fw1.close();
>>>>> } catch (Throwable e) {
>>>>> e.printStackTrace(System.err);
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> The file is written with the security.policy file in place.. If I try
>>>>> to
>>>>> modify a file owned by another user (no OS permissions) then as
>>>>> expected
>>>>> there is raised an exception.
>>>>>
>>>>> Could you tell me what's going wrong?
>>>>>
>>>>> Thanks in advance, your replies are appreciated greatly!
>>>>>
>>>>> On 07/12/2010 05:09 PM, Sander de Groot wrote:
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> For now, I'm using the example code provided in chapter 14. However
>>>>>>>> there
>>>>>>>> arises a (probably) small new problem. I think it's related to
>>>>>>>> different
>>>>>>>> Felix versions used be me and used in the book. (I don't know for
>>>>>>>> sure, I'm
>>>>>>>> using 3.0.1)
>>>>>>>>
>>>>>>>
>>>>>>> You need to use the latest framework.security provider trunk
>>>>>>> (3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
>>>>>>> about that - it should work with framework 3.0.1 so.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Hmm from the trunk. When can I expect a release? It does seem to work
>>>>>> now, I'll test more extensively tomorrow.
>>>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>> After some additional research I've found that the security
>>>>>>>>>> features
>>>>>>>>>> of
>>>>>>>>>> Felix are not as mature as of Equinox.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why not? It would be nice if you could give me some indication
>>>>>>>>> what
>>>>>>>>> your research did find that makes you say that...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have to admit, the statements are a little outdated (2009).
>>>>>>>> At the moment I don't have any references but if you insist I can
>>>>>>>> look
>>>>>>>> them
>>>>>>>> up. But again it isn't that big of an issue because it seems to be
>>>>>>>> working
>>>>>>>> fine.
>>>>>>>> One of the comments made was about the internal implementation, it
>>>>>>>> was
>>>>>>>> said
>>>>>>>> that Felix did not check always the necessary permissions.
>>>>>>>>
>>>>>>>
>>>>>>> Ok, ic, that is outdated. We implement what needs to be implemented
>>>>>>> by
>>>>>>> the spec.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It also seems that the security
>>>>>>>>>> package provided at the felix download page won't start. Is this
>>>>>>>>>> normal?
>>>>>>>>>>
>>>>>>>>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, its an extension bundle (they don't get started).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Of course...
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Sander/
>>>>>>>> /
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What you have to do is to create a dedicated bundle that will
>>>>>>>>>>> play
>>>>>>>>>>> the
>>>>>>>>>>> role of the permission agent.
>>>>>>>>>>>
>>>>>>>>>>> Within this bundle :
>>>>>>>>>>> - get the permission admin service reference
>>>>>>>>>>> - get the permission list
>>>>>>>>>>> - grant allpermission to the system bundle (bundle 0), other
>>>>>>>>>>> Felix
>>>>>>>>>>> bundles
>>>>>>>>>>> may need allpermission
>>>>>>>>>>> - grant allpermission to this permission agent bundle
>>>>>>>>>>> - then grant the different permissions you need to other bundles
>>>>>>>>>>> - commit the permission list to the permission table
>>>>>>>>>>>
>>>>>>>>>>> Then, each time a permission check occurs, the security layer
>>>>>>>>>>> will
>>>>>>>>>>> be
>>>>>>>>>>> able
>>>>>>>>>>> to determine whether each bundle providing each method on the
>>>>>>>>>>> call
>>>>>>>>>>> stack
>>>>>>>>>>> has
>>>>>>>>>>> been granted this particular permission.
>>>>>>>>>>>
>>>>>>>>>>> Actually, as the permission administration is provided as a
>>>>>>>>>>> service, any
>>>>>>>>>>> bundle having sufficient permissions can modify the permission
>>>>>>>>>>> table at
>>>>>>>>>>> any
>>>>>>>>>>> time. So yes, you can therefore add/delete and commit new
>>>>>>>>>>> permissions
>>>>>>>>>>> when
>>>>>>>>>>> catching some specific framework or service events.
>>>>>>>>>>>
>>>>>>>>>>> François
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sander de Groot wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Would it be possible to create a custom bundle which listens to
>>>>>>>>>>>> other
>>>>>>>>>>>> bundles' events and apply a specific permission scheme based on
>>>>>>>>>>>> the for
>>>>>>>>>>>> example bundlename/location or other properties? If so how can I
>>>>>>>>>>>> enforce
>>>>>>>>>>>> such a scheme on another bundle?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Sander
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
Uh, right, how stupid of me.
But I think I know why I didn't include this property because I now get
the following exception:
Exception in thread "main" java.security.AccessControlException: access
denied (java.util.PropertyPermission felix.system.properties read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at java.lang.System.getProperty(System.java:650)
at org.apache.felix.main.Main.loadSystemProperties(Main.java:363)
at org.apache.felix.main.Main.main(Main.java:229)
I only added the property
-Djava.security.manager
It now seems the system is not allowed to read the system properties?
Which is weird because I granted allpermission in all.policy (see below)
On 07/13/2010 04:03 PM, Karl Pauls wrote:
> I think you are missing to add a security manager try to add:
>
> -Djava.security.manager
>
> regards,
>
> Karl
>
>
>
> On Tue, Jul 13, 2010 at 3:57 PM, Sander de Groot<s....@jdi.nl> wrote:
>
>> java -Dlogback.configurationFile=$(pwd)/conf/logback.xml
>> -Djava.security.policy=conf/all.policy -d64 -noverify
>> -javaagent:bin/jrebel.jar -Xdebug -Xnoagent
>> -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -Xms60m
>> -Xmx512m -server -Dfelix.config.properties=file:./conf/config.properties
>> -Djdi.webapps=$(pwd)/webapps -Djdi.webapps.exploded=$(pwd)/webapps/exploded
>> -jar bin/felix.jar
>>
>> I was told to add the all.policy file. This shouldn't be the problem, right?
>> I should probably test it without the all.policy file...
>>
>> all.policy:
>> grant {
>> permission java.lang.AllPermission;
>> };
>>
>>
>>
>> On 07/13/2010 03:33 PM, Richard S. Hall wrote:
>>
>>> Out of curiosity, how are you launching the framework?
>>>
>>> -> richard
>>>
>>> On 7/13/10 8:40, Sander de Groot wrote:
>>>
>>>> After compiling the trunk, felix accepts the input.
>>>> But it still doesn't seem to work, I'm probably doing something wrong..
>>>>
>>>> security.policy:
>>>> DENY {
>>>> ( java.io.FilePermission "*" "*")
>>>> } "Deny all access to files"
>>>> DENY {
>>>> ( java.security.AllPermission "*" "*")
>>>> } "Deny everything"
>>>>
>>>> Running bundles (in this order):
>>>> START LEVEL 1
>>>> ID|State |Level|Name
>>>> 0|Active | 0|System Bundle (3.0.1)
>>>> 1|Active | 1|Logback Classic Module (0.9.24)
>>>> 2|Active | 1|Logback Core Module (0.9.24)
>>>> 3|Active | 1|Apache Felix Bundle Repository (1.6.2)
>>>> 4|Active | 1|Apache Felix Configuration Admin Service (1.2.4)
>>>> 5|Active | 1|Apache Felix EventAdmin (1.2.2)
>>>> 6|Active | 1|Apache Felix File Install (3.0.0)
>>>> 8|Resolved | 1|Apache Felix Security Provider (1.3.0.SNAPSHOT)
>>>> 9|Active | 1|Apache Felix Gogo Command (0.6.0)
>>>> 10|Active | 1|Apache Felix Gogo Runtime (0.6.0)
>>>> 11|Active | 1|Apache Felix Gogo Shell (0.6.0)
>>>> 12|Active | 1|Apache Felix Http Bundle (2.0.4)
>>>> 13|Active | 1|Apache Felix Log Service (1.0.0)
>>>> 14|Active | 1|Apache Felix Shell Service (1.4.2)
>>>> 15|Active | 1|Apache Felix Remote Shell (1.0.4)
>>>> 16|Active | 1|Apache Felix Web Management Console (3.1.0)
>>>> 17|Active | 1|Security Manager (0.0.1.init)
>>>> 18|Active | 1|slf4j-api (1.6.0)
>>>> 19|Active | 1|Webapplication1 (1.0.0.init)
>>>>
>>>> The security manager is the dedicated bundle copied exactly from
>>>> http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example/org.foo.policy/src/org/foo/policy/Activator.java.
>>>> The security manager says it loads the file and I see that the features are
>>>> loaded but the security.policy file still doesn't seem to work.
>>>>
>>>> Relevant code in webapplication 1:
>>>> private void localFile() {
>>>> FileWriter fw1 = null;
>>>> try {
>>>> fw1 = new FileWriter(new
>>>> File("/home/sander/Desktop/test.txt"));
>>>> fw1.write("Hello World!!!\n");
>>>> fw1.write(now("H:mm:ss:SSS"));
>>>> } catch ( Exception e ) {
>>>> System.err.println("Exception: ");
>>>> e.printStackTrace(System.err);
>>>> } finally {
>>>> try {
>>>> fw1.close();
>>>> } catch (Throwable e) {
>>>> e.printStackTrace(System.err);
>>>> }
>>>> }
>>>> }
>>>>
>>>> The file is written with the security.policy file in place.. If I try to
>>>> modify a file owned by another user (no OS permissions) then as expected
>>>> there is raised an exception.
>>>>
>>>> Could you tell me what's going wrong?
>>>>
>>>> Thanks in advance, your replies are appreciated greatly!
>>>>
>>>> On 07/12/2010 05:09 PM, Sander de Groot wrote:
>>>>
>>>>>>
>>>>>>> For now, I'm using the example code provided in chapter 14. However
>>>>>>> there
>>>>>>> arises a (probably) small new problem. I think it's related to
>>>>>>> different
>>>>>>> Felix versions used be me and used in the book. (I don't know for
>>>>>>> sure, I'm
>>>>>>> using 3.0.1)
>>>>>>>
>>>>>> You need to use the latest framework.security provider trunk
>>>>>> (3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
>>>>>> about that - it should work with framework 3.0.1 so.
>>>>>>
>>>>>>
>>>>> Hmm from the trunk. When can I expect a release? It does seem to work
>>>>> now, I'll test more extensively tomorrow.
>>>>>
>>>>>
>>>>>>>>> After some additional research I've found that the security features
>>>>>>>>> of
>>>>>>>>> Felix are not as mature as of Equinox.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Why not? It would be nice if you could give me some indication what
>>>>>>>> your research did find that makes you say that...
>>>>>>>>
>>>>>>>>
>>>>>>> I have to admit, the statements are a little outdated (2009).
>>>>>>> At the moment I don't have any references but if you insist I can look
>>>>>>> them
>>>>>>> up. But again it isn't that big of an issue because it seems to be
>>>>>>> working
>>>>>>> fine.
>>>>>>> One of the comments made was about the internal implementation, it was
>>>>>>> said
>>>>>>> that Felix did not check always the necessary permissions.
>>>>>>>
>>>>>> Ok, ic, that is outdated. We implement what needs to be implemented by
>>>>>> the spec.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>>>>> It also seems that the security
>>>>>>>>> package provided at the felix download page won't start. Is this
>>>>>>>>> normal?
>>>>>>>>>
>>>>>>>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Yes, its an extension bundle (they don't get started).
>>>>>>>>
>>>>>>>>
>>>>>>> Of course...
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Sander/
>>>>>>> /
>>>>>>>
>>>>>>>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> What you have to do is to create a dedicated bundle that will play
>>>>>>>>>> the
>>>>>>>>>> role of the permission agent.
>>>>>>>>>>
>>>>>>>>>> Within this bundle :
>>>>>>>>>> - get the permission admin service reference
>>>>>>>>>> - get the permission list
>>>>>>>>>> - grant allpermission to the system bundle (bundle 0), other Felix
>>>>>>>>>> bundles
>>>>>>>>>> may need allpermission
>>>>>>>>>> - grant allpermission to this permission agent bundle
>>>>>>>>>> - then grant the different permissions you need to other bundles
>>>>>>>>>> - commit the permission list to the permission table
>>>>>>>>>>
>>>>>>>>>> Then, each time a permission check occurs, the security layer will
>>>>>>>>>> be
>>>>>>>>>> able
>>>>>>>>>> to determine whether each bundle providing each method on the call
>>>>>>>>>> stack
>>>>>>>>>> has
>>>>>>>>>> been granted this particular permission.
>>>>>>>>>>
>>>>>>>>>> Actually, as the permission administration is provided as a
>>>>>>>>>> service, any
>>>>>>>>>> bundle having sufficient permissions can modify the permission
>>>>>>>>>> table at
>>>>>>>>>> any
>>>>>>>>>> time. So yes, you can therefore add/delete and commit new
>>>>>>>>>> permissions
>>>>>>>>>> when
>>>>>>>>>> catching some specific framework or service events.
>>>>>>>>>>
>>>>>>>>>> François
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sander de Groot wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Would it be possible to create a custom bundle which listens to
>>>>>>>>>>> other
>>>>>>>>>>> bundles' events and apply a specific permission scheme based on
>>>>>>>>>>> the for
>>>>>>>>>>> example bundlename/location or other properties? If so how can I
>>>>>>>>>>> enforce
>>>>>>>>>>> such a scheme on another bundle?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Sander
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Karl Pauls <ka...@gmail.com>.
I think you are missing to add a security manager try to add:
-Djava.security.manager
regards,
Karl
On Tue, Jul 13, 2010 at 3:57 PM, Sander de Groot <s....@jdi.nl> wrote:
> java -Dlogback.configurationFile=$(pwd)/conf/logback.xml
> -Djava.security.policy=conf/all.policy -d64 -noverify
> -javaagent:bin/jrebel.jar -Xdebug -Xnoagent
> -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -Xms60m
> -Xmx512m -server -Dfelix.config.properties=file:./conf/config.properties
> -Djdi.webapps=$(pwd)/webapps -Djdi.webapps.exploded=$(pwd)/webapps/exploded
> -jar bin/felix.jar
>
> I was told to add the all.policy file. This shouldn't be the problem, right?
> I should probably test it without the all.policy file...
>
> all.policy:
> grant {
> permission java.lang.AllPermission;
> };
>
>
>
> On 07/13/2010 03:33 PM, Richard S. Hall wrote:
>>
>> Out of curiosity, how are you launching the framework?
>>
>> -> richard
>>
>> On 7/13/10 8:40, Sander de Groot wrote:
>>>
>>> After compiling the trunk, felix accepts the input.
>>> But it still doesn't seem to work, I'm probably doing something wrong..
>>>
>>> security.policy:
>>> DENY {
>>> ( java.io.FilePermission "*" "*")
>>> } "Deny all access to files"
>>> DENY {
>>> ( java.security.AllPermission "*" "*")
>>> } "Deny everything"
>>>
>>> Running bundles (in this order):
>>> START LEVEL 1
>>> ID|State |Level|Name
>>> 0|Active | 0|System Bundle (3.0.1)
>>> 1|Active | 1|Logback Classic Module (0.9.24)
>>> 2|Active | 1|Logback Core Module (0.9.24)
>>> 3|Active | 1|Apache Felix Bundle Repository (1.6.2)
>>> 4|Active | 1|Apache Felix Configuration Admin Service (1.2.4)
>>> 5|Active | 1|Apache Felix EventAdmin (1.2.2)
>>> 6|Active | 1|Apache Felix File Install (3.0.0)
>>> 8|Resolved | 1|Apache Felix Security Provider (1.3.0.SNAPSHOT)
>>> 9|Active | 1|Apache Felix Gogo Command (0.6.0)
>>> 10|Active | 1|Apache Felix Gogo Runtime (0.6.0)
>>> 11|Active | 1|Apache Felix Gogo Shell (0.6.0)
>>> 12|Active | 1|Apache Felix Http Bundle (2.0.4)
>>> 13|Active | 1|Apache Felix Log Service (1.0.0)
>>> 14|Active | 1|Apache Felix Shell Service (1.4.2)
>>> 15|Active | 1|Apache Felix Remote Shell (1.0.4)
>>> 16|Active | 1|Apache Felix Web Management Console (3.1.0)
>>> 17|Active | 1|Security Manager (0.0.1.init)
>>> 18|Active | 1|slf4j-api (1.6.0)
>>> 19|Active | 1|Webapplication1 (1.0.0.init)
>>>
>>> The security manager is the dedicated bundle copied exactly from
>>> http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example/org.foo.policy/src/org/foo/policy/Activator.java.
>>> The security manager says it loads the file and I see that the features are
>>> loaded but the security.policy file still doesn't seem to work.
>>>
>>> Relevant code in webapplication 1:
>>> private void localFile() {
>>> FileWriter fw1 = null;
>>> try {
>>> fw1 = new FileWriter(new
>>> File("/home/sander/Desktop/test.txt"));
>>> fw1.write("Hello World!!!\n");
>>> fw1.write(now("H:mm:ss:SSS"));
>>> } catch ( Exception e ) {
>>> System.err.println("Exception: ");
>>> e.printStackTrace(System.err);
>>> } finally {
>>> try {
>>> fw1.close();
>>> } catch (Throwable e) {
>>> e.printStackTrace(System.err);
>>> }
>>> }
>>> }
>>>
>>> The file is written with the security.policy file in place.. If I try to
>>> modify a file owned by another user (no OS permissions) then as expected
>>> there is raised an exception.
>>>
>>> Could you tell me what's going wrong?
>>>
>>> Thanks in advance, your replies are appreciated greatly!
>>>
>>> On 07/12/2010 05:09 PM, Sander de Groot wrote:
>>>>>
>>>>>> For now, I'm using the example code provided in chapter 14. However
>>>>>> there
>>>>>> arises a (probably) small new problem. I think it's related to
>>>>>> different
>>>>>> Felix versions used be me and used in the book. (I don't know for
>>>>>> sure, I'm
>>>>>> using 3.0.1)
>>>>>
>>>>> You need to use the latest framework.security provider trunk
>>>>> (3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
>>>>> about that - it should work with framework 3.0.1 so.
>>>>>
>>>> Hmm from the trunk. When can I expect a release? It does seem to work
>>>> now, I'll test more extensively tomorrow.
>>>>
>>>>>>>> After some additional research I've found that the security features
>>>>>>>> of
>>>>>>>> Felix are not as mature as of Equinox.
>>>>>>>>
>>>>>>> Why not? It would be nice if you could give me some indication what
>>>>>>> your research did find that makes you say that...
>>>>>>>
>>>>>> I have to admit, the statements are a little outdated (2009).
>>>>>> At the moment I don't have any references but if you insist I can look
>>>>>> them
>>>>>> up. But again it isn't that big of an issue because it seems to be
>>>>>> working
>>>>>> fine.
>>>>>> One of the comments made was about the internal implementation, it was
>>>>>> said
>>>>>> that Felix did not check always the necessary permissions.
>>>>>
>>>>> Ok, ic, that is outdated. We implement what needs to be implemented by
>>>>> the spec.
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>>>> It also seems that the security
>>>>>>>> package provided at the felix download page won't start. Is this
>>>>>>>> normal?
>>>>>>>>
>>>>>>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>>>>>>
>>>>>>> Yes, its an extension bundle (they don't get started).
>>>>>>>
>>>>>> Of course...
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Sander/
>>>>>> /
>>>>>>>>
>>>>>>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>>>>>>
>>>>>>>>> What you have to do is to create a dedicated bundle that will play
>>>>>>>>> the
>>>>>>>>> role of the permission agent.
>>>>>>>>>
>>>>>>>>> Within this bundle :
>>>>>>>>> - get the permission admin service reference
>>>>>>>>> - get the permission list
>>>>>>>>> - grant allpermission to the system bundle (bundle 0), other Felix
>>>>>>>>> bundles
>>>>>>>>> may need allpermission
>>>>>>>>> - grant allpermission to this permission agent bundle
>>>>>>>>> - then grant the different permissions you need to other bundles
>>>>>>>>> - commit the permission list to the permission table
>>>>>>>>>
>>>>>>>>> Then, each time a permission check occurs, the security layer will
>>>>>>>>> be
>>>>>>>>> able
>>>>>>>>> to determine whether each bundle providing each method on the call
>>>>>>>>> stack
>>>>>>>>> has
>>>>>>>>> been granted this particular permission.
>>>>>>>>>
>>>>>>>>> Actually, as the permission administration is provided as a
>>>>>>>>> service, any
>>>>>>>>> bundle having sufficient permissions can modify the permission
>>>>>>>>> table at
>>>>>>>>> any
>>>>>>>>> time. So yes, you can therefore add/delete and commit new
>>>>>>>>> permissions
>>>>>>>>> when
>>>>>>>>> catching some specific framework or service events.
>>>>>>>>>
>>>>>>>>> François
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sander de Groot wrote:
>>>>>>>>>
>>>>>>>>>> Would it be possible to create a custom bundle which listens to
>>>>>>>>>> other
>>>>>>>>>> bundles' events and apply a specific permission scheme based on
>>>>>>>>>> the for
>>>>>>>>>> example bundlename/location or other properties? If so how can I
>>>>>>>>>> enforce
>>>>>>>>>> such a scheme on another bundle?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Sander
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
java -Dlogback.configurationFile=$(pwd)/conf/logback.xml
-Djava.security.policy=conf/all.policy -d64 -noverify
-javaagent:bin/jrebel.jar -Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -Xms60m
-Xmx512m -server -Dfelix.config.properties=file:./conf/config.properties
-Djdi.webapps=$(pwd)/webapps
-Djdi.webapps.exploded=$(pwd)/webapps/exploded -jar bin/felix.jar
I was told to add the all.policy file. This shouldn't be the problem,
right? I should probably test it without the all.policy file...
all.policy:
grant {
permission java.lang.AllPermission;
};
On 07/13/2010 03:33 PM, Richard S. Hall wrote:
> Out of curiosity, how are you launching the framework?
>
> -> richard
>
> On 7/13/10 8:40, Sander de Groot wrote:
>> After compiling the trunk, felix accepts the input.
>> But it still doesn't seem to work, I'm probably doing something wrong..
>>
>> security.policy:
>> DENY {
>> ( java.io.FilePermission "*" "*")
>> } "Deny all access to files"
>> DENY {
>> ( java.security.AllPermission "*" "*")
>> } "Deny everything"
>>
>> Running bundles (in this order):
>> START LEVEL 1
>> ID|State |Level|Name
>> 0|Active | 0|System Bundle (3.0.1)
>> 1|Active | 1|Logback Classic Module (0.9.24)
>> 2|Active | 1|Logback Core Module (0.9.24)
>> 3|Active | 1|Apache Felix Bundle Repository (1.6.2)
>> 4|Active | 1|Apache Felix Configuration Admin Service (1.2.4)
>> 5|Active | 1|Apache Felix EventAdmin (1.2.2)
>> 6|Active | 1|Apache Felix File Install (3.0.0)
>> 8|Resolved | 1|Apache Felix Security Provider (1.3.0.SNAPSHOT)
>> 9|Active | 1|Apache Felix Gogo Command (0.6.0)
>> 10|Active | 1|Apache Felix Gogo Runtime (0.6.0)
>> 11|Active | 1|Apache Felix Gogo Shell (0.6.0)
>> 12|Active | 1|Apache Felix Http Bundle (2.0.4)
>> 13|Active | 1|Apache Felix Log Service (1.0.0)
>> 14|Active | 1|Apache Felix Shell Service (1.4.2)
>> 15|Active | 1|Apache Felix Remote Shell (1.0.4)
>> 16|Active | 1|Apache Felix Web Management Console (3.1.0)
>> 17|Active | 1|Security Manager (0.0.1.init)
>> 18|Active | 1|slf4j-api (1.6.0)
>> 19|Active | 1|Webapplication1 (1.0.0.init)
>>
>> The security manager is the dedicated bundle copied exactly from
>> http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example/org.foo.policy/src/org/foo/policy/Activator.java.
>> The security manager says it loads the file and I see that the
>> features are loaded but the security.policy file still doesn't seem
>> to work.
>>
>> Relevant code in webapplication 1:
>> private void localFile() {
>> FileWriter fw1 = null;
>> try {
>> fw1 = new FileWriter(new
>> File("/home/sander/Desktop/test.txt"));
>> fw1.write("Hello World!!!\n");
>> fw1.write(now("H:mm:ss:SSS"));
>> } catch ( Exception e ) {
>> System.err.println("Exception: ");
>> e.printStackTrace(System.err);
>> } finally {
>> try {
>> fw1.close();
>> } catch (Throwable e) {
>> e.printStackTrace(System.err);
>> }
>> }
>> }
>>
>> The file is written with the security.policy file in place.. If I try
>> to modify a file owned by another user (no OS permissions) then as
>> expected there is raised an exception.
>>
>> Could you tell me what's going wrong?
>>
>> Thanks in advance, your replies are appreciated greatly!
>>
>> On 07/12/2010 05:09 PM, Sander de Groot wrote:
>>>>
>>>>> For now, I'm using the example code provided in chapter 14.
>>>>> However there
>>>>> arises a (probably) small new problem. I think it's related to
>>>>> different
>>>>> Felix versions used be me and used in the book. (I don't know for
>>>>> sure, I'm
>>>>> using 3.0.1)
>>>> You need to use the latest framework.security provider trunk
>>>> (3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
>>>> about that - it should work with framework 3.0.1 so.
>>>>
>>> Hmm from the trunk. When can I expect a release? It does seem to
>>> work now, I'll test more extensively tomorrow.
>>>
>>>>>>> After some additional research I've found that the security
>>>>>>> features of
>>>>>>> Felix are not as mature as of Equinox.
>>>>>>>
>>>>>> Why not? It would be nice if you could give me some indication what
>>>>>> your research did find that makes you say that...
>>>>>>
>>>>> I have to admit, the statements are a little outdated (2009).
>>>>> At the moment I don't have any references but if you insist I can
>>>>> look them
>>>>> up. But again it isn't that big of an issue because it seems to be
>>>>> working
>>>>> fine.
>>>>> One of the comments made was about the internal implementation, it
>>>>> was said
>>>>> that Felix did not check always the necessary permissions.
>>>> Ok, ic, that is outdated. We implement what needs to be implemented
>>>> by the spec.
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>>>>> It also seems that the security
>>>>>>> package provided at the felix download page won't start. Is this
>>>>>>> normal?
>>>>>>>
>>>>>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>>>>>
>>>>>> Yes, its an extension bundle (they don't get started).
>>>>>>
>>>>> Of course...
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Sander/
>>>>> /
>>>>>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>>>>>
>>>>>>>> What you have to do is to create a dedicated bundle that will
>>>>>>>> play the
>>>>>>>> role of the permission agent.
>>>>>>>>
>>>>>>>> Within this bundle :
>>>>>>>> - get the permission admin service reference
>>>>>>>> - get the permission list
>>>>>>>> - grant allpermission to the system bundle (bundle 0), other Felix
>>>>>>>> bundles
>>>>>>>> may need allpermission
>>>>>>>> - grant allpermission to this permission agent bundle
>>>>>>>> - then grant the different permissions you need to other bundles
>>>>>>>> - commit the permission list to the permission table
>>>>>>>>
>>>>>>>> Then, each time a permission check occurs, the security layer
>>>>>>>> will be
>>>>>>>> able
>>>>>>>> to determine whether each bundle providing each method on the
>>>>>>>> call stack
>>>>>>>> has
>>>>>>>> been granted this particular permission.
>>>>>>>>
>>>>>>>> Actually, as the permission administration is provided as a
>>>>>>>> service, any
>>>>>>>> bundle having sufficient permissions can modify the permission
>>>>>>>> table at
>>>>>>>> any
>>>>>>>> time. So yes, you can therefore add/delete and commit new
>>>>>>>> permissions
>>>>>>>> when
>>>>>>>> catching some specific framework or service events.
>>>>>>>>
>>>>>>>> François
>>>>>>>>
>>>>>>>>
>>>>>>>> Sander de Groot wrote:
>>>>>>>>
>>>>>>>>> Would it be possible to create a custom bundle which listens
>>>>>>>>> to other
>>>>>>>>> bundles' events and apply a specific permission scheme based
>>>>>>>>> on the for
>>>>>>>>> example bundlename/location or other properties? If so how can I
>>>>>>>>> enforce
>>>>>>>>> such a scheme on another bundle?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Sander
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Out of curiosity, how are you launching the framework?
-> richard
On 7/13/10 8:40, Sander de Groot wrote:
> After compiling the trunk, felix accepts the input.
> But it still doesn't seem to work, I'm probably doing something wrong..
>
> security.policy:
> DENY {
> ( java.io.FilePermission "*" "*")
> } "Deny all access to files"
> DENY {
> ( java.security.AllPermission "*" "*")
> } "Deny everything"
>
> Running bundles (in this order):
> START LEVEL 1
> ID|State |Level|Name
> 0|Active | 0|System Bundle (3.0.1)
> 1|Active | 1|Logback Classic Module (0.9.24)
> 2|Active | 1|Logback Core Module (0.9.24)
> 3|Active | 1|Apache Felix Bundle Repository (1.6.2)
> 4|Active | 1|Apache Felix Configuration Admin Service (1.2.4)
> 5|Active | 1|Apache Felix EventAdmin (1.2.2)
> 6|Active | 1|Apache Felix File Install (3.0.0)
> 8|Resolved | 1|Apache Felix Security Provider (1.3.0.SNAPSHOT)
> 9|Active | 1|Apache Felix Gogo Command (0.6.0)
> 10|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> 11|Active | 1|Apache Felix Gogo Shell (0.6.0)
> 12|Active | 1|Apache Felix Http Bundle (2.0.4)
> 13|Active | 1|Apache Felix Log Service (1.0.0)
> 14|Active | 1|Apache Felix Shell Service (1.4.2)
> 15|Active | 1|Apache Felix Remote Shell (1.0.4)
> 16|Active | 1|Apache Felix Web Management Console (3.1.0)
> 17|Active | 1|Security Manager (0.0.1.init)
> 18|Active | 1|slf4j-api (1.6.0)
> 19|Active | 1|Webapplication1 (1.0.0.init)
>
> The security manager is the dedicated bundle copied exactly from
> http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example/org.foo.policy/src/org/foo/policy/Activator.java.
> The security manager says it loads the file and I see that the
> features are loaded but the security.policy file still doesn't seem to
> work.
>
> Relevant code in webapplication 1:
> private void localFile() {
> FileWriter fw1 = null;
> try {
> fw1 = new FileWriter(new
> File("/home/sander/Desktop/test.txt"));
> fw1.write("Hello World!!!\n");
> fw1.write(now("H:mm:ss:SSS"));
> } catch ( Exception e ) {
> System.err.println("Exception: ");
> e.printStackTrace(System.err);
> } finally {
> try {
> fw1.close();
> } catch (Throwable e) {
> e.printStackTrace(System.err);
> }
> }
> }
>
> The file is written with the security.policy file in place.. If I try
> to modify a file owned by another user (no OS permissions) then as
> expected there is raised an exception.
>
> Could you tell me what's going wrong?
>
> Thanks in advance, your replies are appreciated greatly!
>
> On 07/12/2010 05:09 PM, Sander de Groot wrote:
>>>
>>>> For now, I'm using the example code provided in chapter 14. However
>>>> there
>>>> arises a (probably) small new problem. I think it's related to
>>>> different
>>>> Felix versions used be me and used in the book. (I don't know for
>>>> sure, I'm
>>>> using 3.0.1)
>>> You need to use the latest framework.security provider trunk
>>> (3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
>>> about that - it should work with framework 3.0.1 so.
>>>
>> Hmm from the trunk. When can I expect a release? It does seem to work
>> now, I'll test more extensively tomorrow.
>>
>>>>>> After some additional research I've found that the security
>>>>>> features of
>>>>>> Felix are not as mature as of Equinox.
>>>>>>
>>>>> Why not? It would be nice if you could give me some indication what
>>>>> your research did find that makes you say that...
>>>>>
>>>> I have to admit, the statements are a little outdated (2009).
>>>> At the moment I don't have any references but if you insist I can
>>>> look them
>>>> up. But again it isn't that big of an issue because it seems to be
>>>> working
>>>> fine.
>>>> One of the comments made was about the internal implementation, it
>>>> was said
>>>> that Felix did not check always the necessary permissions.
>>> Ok, ic, that is outdated. We implement what needs to be implemented
>>> by the spec.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>>>> It also seems that the security
>>>>>> package provided at the felix download page won't start. Is this
>>>>>> normal?
>>>>>>
>>>>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>>>>
>>>>> Yes, its an extension bundle (they don't get started).
>>>>>
>>>> Of course...
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Sander/
>>>> /
>>>>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>>>>
>>>>>>> What you have to do is to create a dedicated bundle that will
>>>>>>> play the
>>>>>>> role of the permission agent.
>>>>>>>
>>>>>>> Within this bundle :
>>>>>>> - get the permission admin service reference
>>>>>>> - get the permission list
>>>>>>> - grant allpermission to the system bundle (bundle 0), other Felix
>>>>>>> bundles
>>>>>>> may need allpermission
>>>>>>> - grant allpermission to this permission agent bundle
>>>>>>> - then grant the different permissions you need to other bundles
>>>>>>> - commit the permission list to the permission table
>>>>>>>
>>>>>>> Then, each time a permission check occurs, the security layer
>>>>>>> will be
>>>>>>> able
>>>>>>> to determine whether each bundle providing each method on the
>>>>>>> call stack
>>>>>>> has
>>>>>>> been granted this particular permission.
>>>>>>>
>>>>>>> Actually, as the permission administration is provided as a
>>>>>>> service, any
>>>>>>> bundle having sufficient permissions can modify the permission
>>>>>>> table at
>>>>>>> any
>>>>>>> time. So yes, you can therefore add/delete and commit new
>>>>>>> permissions
>>>>>>> when
>>>>>>> catching some specific framework or service events.
>>>>>>>
>>>>>>> François
>>>>>>>
>>>>>>>
>>>>>>> Sander de Groot wrote:
>>>>>>>
>>>>>>>> Would it be possible to create a custom bundle which listens to
>>>>>>>> other
>>>>>>>> bundles' events and apply a specific permission scheme based on
>>>>>>>> the for
>>>>>>>> example bundlename/location or other properties? If so how can I
>>>>>>>> enforce
>>>>>>>> such a scheme on another bundle?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Sander
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
After compiling the trunk, felix accepts the input.
But it still doesn't seem to work, I'm probably doing something wrong..
security.policy:
DENY {
( java.io.FilePermission "*" "*")
} "Deny all access to files"
DENY {
( java.security.AllPermission "*" "*")
} "Deny everything"
Running bundles (in this order):
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (3.0.1)
1|Active | 1|Logback Classic Module (0.9.24)
2|Active | 1|Logback Core Module (0.9.24)
3|Active | 1|Apache Felix Bundle Repository (1.6.2)
4|Active | 1|Apache Felix Configuration Admin Service (1.2.4)
5|Active | 1|Apache Felix EventAdmin (1.2.2)
6|Active | 1|Apache Felix File Install (3.0.0)
8|Resolved | 1|Apache Felix Security Provider (1.3.0.SNAPSHOT)
9|Active | 1|Apache Felix Gogo Command (0.6.0)
10|Active | 1|Apache Felix Gogo Runtime (0.6.0)
11|Active | 1|Apache Felix Gogo Shell (0.6.0)
12|Active | 1|Apache Felix Http Bundle (2.0.4)
13|Active | 1|Apache Felix Log Service (1.0.0)
14|Active | 1|Apache Felix Shell Service (1.4.2)
15|Active | 1|Apache Felix Remote Shell (1.0.4)
16|Active | 1|Apache Felix Web Management Console (3.1.0)
17|Active | 1|Security Manager (0.0.1.init)
18|Active | 1|slf4j-api (1.6.0)
19|Active | 1|Webapplication1 (1.0.0.init)
The security manager is the dedicated bundle copied exactly from
http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example/org.foo.policy/src/org/foo/policy/Activator.java.
The security manager says it loads the file and I see that the features
are loaded but the security.policy file still doesn't seem to work.
Relevant code in webapplication 1:
private void localFile() {
FileWriter fw1 = null;
try {
fw1 = new FileWriter(new
File("/home/sander/Desktop/test.txt"));
fw1.write("Hello World!!!\n");
fw1.write(now("H:mm:ss:SSS"));
} catch ( Exception e ) {
System.err.println("Exception: ");
e.printStackTrace(System.err);
} finally {
try {
fw1.close();
} catch (Throwable e) {
e.printStackTrace(System.err);
}
}
}
The file is written with the security.policy file in place.. If I try to
modify a file owned by another user (no OS permissions) then as expected
there is raised an exception.
Could you tell me what's going wrong?
Thanks in advance, your replies are appreciated greatly!
On 07/12/2010 05:09 PM, Sander de Groot wrote:
>>
>>> For now, I'm using the example code provided in chapter 14. However
>>> there
>>> arises a (probably) small new problem. I think it's related to
>>> different
>>> Felix versions used be me and used in the book. (I don't know for
>>> sure, I'm
>>> using 3.0.1)
>> You need to use the latest framework.security provider trunk
>> (3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
>> about that - it should work with framework 3.0.1 so.
>>
> Hmm from the trunk. When can I expect a release? It does seem to work
> now, I'll test more extensively tomorrow.
>
>>>>> After some additional research I've found that the security
>>>>> features of
>>>>> Felix are not as mature as of Equinox.
>>>>>
>>>> Why not? It would be nice if you could give me some indication what
>>>> your research did find that makes you say that...
>>>>
>>> I have to admit, the statements are a little outdated (2009).
>>> At the moment I don't have any references but if you insist I can
>>> look them
>>> up. But again it isn't that big of an issue because it seems to be
>>> working
>>> fine.
>>> One of the comments made was about the internal implementation, it
>>> was said
>>> that Felix did not check always the necessary permissions.
>> Ok, ic, that is outdated. We implement what needs to be implemented
>> by the spec.
>>
>> regards,
>>
>> Karl
>>
>>>>> It also seems that the security
>>>>> package provided at the felix download page won't start. Is this
>>>>> normal?
>>>>>
>>>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>>>
>>>> Yes, its an extension bundle (they don't get started).
>>>>
>>> Of course...
>>>
>>>
>>> Regards,
>>>
>>> Sander/
>>> /
>>>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>>>
>>>>>> What you have to do is to create a dedicated bundle that will
>>>>>> play the
>>>>>> role of the permission agent.
>>>>>>
>>>>>> Within this bundle :
>>>>>> - get the permission admin service reference
>>>>>> - get the permission list
>>>>>> - grant allpermission to the system bundle (bundle 0), other Felix
>>>>>> bundles
>>>>>> may need allpermission
>>>>>> - grant allpermission to this permission agent bundle
>>>>>> - then grant the different permissions you need to other bundles
>>>>>> - commit the permission list to the permission table
>>>>>>
>>>>>> Then, each time a permission check occurs, the security layer
>>>>>> will be
>>>>>> able
>>>>>> to determine whether each bundle providing each method on the
>>>>>> call stack
>>>>>> has
>>>>>> been granted this particular permission.
>>>>>>
>>>>>> Actually, as the permission administration is provided as a
>>>>>> service, any
>>>>>> bundle having sufficient permissions can modify the permission
>>>>>> table at
>>>>>> any
>>>>>> time. So yes, you can therefore add/delete and commit new
>>>>>> permissions
>>>>>> when
>>>>>> catching some specific framework or service events.
>>>>>>
>>>>>> François
>>>>>>
>>>>>>
>>>>>> Sander de Groot wrote:
>>>>>>
>>>>>>> Would it be possible to create a custom bundle which listens to
>>>>>>> other
>>>>>>> bundles' events and apply a specific permission scheme based on
>>>>>>> the for
>>>>>>> example bundlename/location or other properties? If so how can I
>>>>>>> enforce
>>>>>>> such a scheme on another bundle?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Sander
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
>
>> For now, I'm using the example code provided in chapter 14. However there
>> arises a (probably) small new problem. I think it's related to different
>> Felix versions used be me and used in the book. (I don't know for sure, I'm
>> using 3.0.1)
>>
> You need to use the latest framework.security provider trunk
> (3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
> about that - it should work with framework 3.0.1 so.
>
>
Hmm from the trunk. When can I expect a release? It does seem to work
now, I'll test more extensively tomorrow.
>>>> After some additional research I've found that the security features of
>>>> Felix are not as mature as of Equinox.
>>>>
>>>>
>>> Why not? It would be nice if you could give me some indication what
>>> your research did find that makes you say that...
>>>
>>>
>> I have to admit, the statements are a little outdated (2009).
>> At the moment I don't have any references but if you insist I can look them
>> up. But again it isn't that big of an issue because it seems to be working
>> fine.
>> One of the comments made was about the internal implementation, it was said
>> that Felix did not check always the necessary permissions.
>>
> Ok, ic, that is outdated. We implement what needs to be implemented by the spec.
>
> regards,
>
> Karl
>
>
>>>> It also seems that the security
>>>> package provided at the felix download page won't start. Is this normal?
>>>>
>>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>>
>>>>
>>> Yes, its an extension bundle (they don't get started).
>>>
>>>
>> Of course...
>>
>>
>> Regards,
>>
>> Sander/
>> /
>>
>>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>>
>>>>
>>>>> What you have to do is to create a dedicated bundle that will play the
>>>>> role of the permission agent.
>>>>>
>>>>> Within this bundle :
>>>>> - get the permission admin service reference
>>>>> - get the permission list
>>>>> - grant allpermission to the system bundle (bundle 0), other Felix
>>>>> bundles
>>>>> may need allpermission
>>>>> - grant allpermission to this permission agent bundle
>>>>> - then grant the different permissions you need to other bundles
>>>>> - commit the permission list to the permission table
>>>>>
>>>>> Then, each time a permission check occurs, the security layer will be
>>>>> able
>>>>> to determine whether each bundle providing each method on the call stack
>>>>> has
>>>>> been granted this particular permission.
>>>>>
>>>>> Actually, as the permission administration is provided as a service, any
>>>>> bundle having sufficient permissions can modify the permission table at
>>>>> any
>>>>> time. So yes, you can therefore add/delete and commit new permissions
>>>>> when
>>>>> catching some specific framework or service events.
>>>>>
>>>>> François
>>>>>
>>>>>
>>>>> Sander de Groot wrote:
>>>>>
>>>>>
>>>>>> Would it be possible to create a custom bundle which listens to other
>>>>>> bundles' events and apply a specific permission scheme based on the for
>>>>>> example bundlename/location or other properties? If so how can I
>>>>>> enforce
>>>>>> such a scheme on another bundle?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Sander
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Jul 12, 2010 at 2:33 PM, Sander de Groot <s....@jdi.nl> wrote:
> Hi Karl,
>
> Thanks for your reply.
>
> On 07/12/2010 11:08 AM, Karl Pauls wrote:
>>>
>>> Questions that arose while creating the above snippet:
>>> - Should I remove permissions if my dedicated bundle is
>>> reloaded/stopped?
>>> - How can I remove permissions?
>>>
>>
>> Just clear the condpermupdate list and commit it. Better yet, keep a
>> copy around and restore the previous permissions if you go away.
>>
>
> I've used the example code of chapter 14 and this is clear now. Thanks.
Great :-)
>>> - Is there a bundle which translates a textfile (properties/xml or
>>> whatsoever) so I won't have to hard-code the whole permission scheme?
>>>
>>
>> You could have a look at the source code for chapter14 of the OSGi in
>> Action book. We have an example which uses a simple txt file and does
>> what you are asking for
>> (http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example
>> - look into the org.foo.policy bundle). In general, it sounds like
>> chapter14 might be interesting for you (the next meap update will have
>> a more advanced example where the policy bundle is explained too).
>>
>
> I intend to buy the book as soon as it is released, I think it will clarify
> a lot for me.
You can get it via the manning meap right now if you want to (but
waiting is ok as well :-)
> For now, I'm using the example code provided in chapter 14. However there
> arises a (probably) small new problem. I think it's related to different
> Felix versions used be me and used in the book. (I don't know for sure, I'm
> using 3.0.1)
You need to use the latest framework.security provider trunk
(3.1.0-SNAPSHOT) for the policy bundle to work. Sorry, didn't think
about that - it should work with framework 3.0.1 so.
> I only added some debug information to the provided example nothing else.
> Also, the security.policy file is identical to the one provided.
>
> Using security policy file: /home/sander/Programs/jdiserver/security.policy
> java.lang.IllegalArgumentException
> at
> org.apache.felix.framework.security.condpermadmin.ConditionalPermissionInfoImpl.<init>(ConditionalPermissionInfoImpl.java:54)
> at
> org.apache.felix.framework.security.condpermadmin.ConditionalPermissionAdminImpl.newConditionalPermissionInfo(ConditionalPermissionAdminImpl.java:1119)
> at nl.jdi.osgi.security.Activator.setUpPolicy(Activator.java:92)
> at nl.jdi.osgi.security.Activator.start(Activator.java:60)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1862)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1779)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1188)
> at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
> at java.lang.Thread.run(Thread.java:619)
> Could not add permissioninfo... ALLOW { [
> org.osgi.service.condpermadmin.BundleSignerCondition "CN=core, O=baz, C=DE"
> ] ( java.security.AllPermission "*" "*")} "Bundles Signed by core get
> AllPermission"
>
> It seems that the encoded string representation is invalid?
Yeah, i changed that and it is working now but with an unreleased
version of the security provider. If you build the current trunk for
framework.security it should work.
>>> After some additional research I've found that the security features of
>>> Felix are not as mature as of Equinox.
>>>
>>
>> Why not? It would be nice if you could give me some indication what
>> your research did find that makes you say that...
>>
>
> I have to admit, the statements are a little outdated (2009).
> At the moment I don't have any references but if you insist I can look them
> up. But again it isn't that big of an issue because it seems to be working
> fine.
> One of the comments made was about the internal implementation, it was said
> that Felix did not check always the necessary permissions.
Ok, ic, that is outdated. We implement what needs to be implemented by the spec.
regards,
Karl
>>> It also seems that the security
>>> package provided at the felix download page won't start. Is this normal?
>>>
>>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>>
>>
>> Yes, its an extension bundle (they don't get started).
>>
>
> Of course...
>
>
> Regards,
>
> Sander/
> /
>>>
>>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>>
>>>>
>>>> What you have to do is to create a dedicated bundle that will play the
>>>> role of the permission agent.
>>>>
>>>> Within this bundle :
>>>> - get the permission admin service reference
>>>> - get the permission list
>>>> - grant allpermission to the system bundle (bundle 0), other Felix
>>>> bundles
>>>> may need allpermission
>>>> - grant allpermission to this permission agent bundle
>>>> - then grant the different permissions you need to other bundles
>>>> - commit the permission list to the permission table
>>>>
>>>> Then, each time a permission check occurs, the security layer will be
>>>> able
>>>> to determine whether each bundle providing each method on the call stack
>>>> has
>>>> been granted this particular permission.
>>>>
>>>> Actually, as the permission administration is provided as a service, any
>>>> bundle having sufficient permissions can modify the permission table at
>>>> any
>>>> time. So yes, you can therefore add/delete and commit new permissions
>>>> when
>>>> catching some specific framework or service events.
>>>>
>>>> François
>>>>
>>>>
>>>> Sander de Groot wrote:
>>>>
>>>>>
>>>>> Would it be possible to create a custom bundle which listens to other
>>>>> bundles' events and apply a specific permission scheme based on the for
>>>>> example bundlename/location or other properties? If so how can I
>>>>> enforce
>>>>> such a scheme on another bundle?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Sander
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
Hi Karl,
Thanks for your reply.
On 07/12/2010 11:08 AM, Karl Pauls wrote:
>> Questions that arose while creating the above snippet:
>> - Should I remove permissions if my dedicated bundle is reloaded/stopped?
>> - How can I remove permissions?
>>
> Just clear the condpermupdate list and commit it. Better yet, keep a
> copy around and restore the previous permissions if you go away.
>
I've used the example code of chapter 14 and this is clear now. Thanks.
>> - Is there a bundle which translates a textfile (properties/xml or
>> whatsoever) so I won't have to hard-code the whole permission scheme?
>>
> You could have a look at the source code for chapter14 of the OSGi in
> Action book. We have an example which uses a simple txt file and does
> what you are asking for
> (http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example
> - look into the org.foo.policy bundle). In general, it sounds like
> chapter14 might be interesting for you (the next meap update will have
> a more advanced example where the policy bundle is explained too).
>
I intend to buy the book as soon as it is released, I think it will
clarify a lot for me.
For now, I'm using the example code provided in chapter 14. However
there arises a (probably) small new problem. I think it's related to
different Felix versions used be me and used in the book. (I don't know
for sure, I'm using 3.0.1)
I only added some debug information to the provided example nothing
else. Also, the security.policy file is identical to the one provided.
Using security policy file: /home/sander/Programs/jdiserver/security.policy
java.lang.IllegalArgumentException
at
org.apache.felix.framework.security.condpermadmin.ConditionalPermissionInfoImpl.<init>(ConditionalPermissionInfoImpl.java:54)
at
org.apache.felix.framework.security.condpermadmin.ConditionalPermissionAdminImpl.newConditionalPermissionInfo(ConditionalPermissionAdminImpl.java:1119)
at nl.jdi.osgi.security.Activator.setUpPolicy(Activator.java:92)
at nl.jdi.osgi.security.Activator.start(Activator.java:60)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1862)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1779)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1188)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:619)
Could not add permissioninfo... ALLOW { [
org.osgi.service.condpermadmin.BundleSignerCondition "CN=core, O=baz,
C=DE" ] ( java.security.AllPermission "*" "*")} "Bundles Signed by
core get AllPermission"
It seems that the encoded string representation is invalid?
>> After some additional research I've found that the security features of
>> Felix are not as mature as of Equinox.
>>
> Why not? It would be nice if you could give me some indication what
> your research did find that makes you say that...
>
I have to admit, the statements are a little outdated (2009).
At the moment I don't have any references but if you insist I can look
them up. But again it isn't that big of an issue because it seems to be
working fine.
One of the comments made was about the internal implementation, it was
said that Felix did not check always the necessary permissions.
>> It also seems that the security
>> package provided at the felix download page won't start. Is this normal?
>>
>> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
>>
> Yes, its an extension bundle (they don't get started).
>
Of course...
Regards,
Sander/
/
>> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>
>>> What you have to do is to create a dedicated bundle that will play the
>>> role of the permission agent.
>>>
>>> Within this bundle :
>>> - get the permission admin service reference
>>> - get the permission list
>>> - grant allpermission to the system bundle (bundle 0), other Felix bundles
>>> may need allpermission
>>> - grant allpermission to this permission agent bundle
>>> - then grant the different permissions you need to other bundles
>>> - commit the permission list to the permission table
>>>
>>> Then, each time a permission check occurs, the security layer will be able
>>> to determine whether each bundle providing each method on the call stack has
>>> been granted this particular permission.
>>>
>>> Actually, as the permission administration is provided as a service, any
>>> bundle having sufficient permissions can modify the permission table at any
>>> time. So yes, you can therefore add/delete and commit new permissions when
>>> catching some specific framework or service events.
>>>
>>> François
>>>
>>>
>>> Sander de Groot wrote:
>>>
>>>> Would it be possible to create a custom bundle which listens to other
>>>> bundles' events and apply a specific permission scheme based on the for
>>>> example bundlename/location or other properties? If so how can I enforce
>>>> such a scheme on another bundle?
>>>>
>>>> Regards,
>>>>
>>>> Sander
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Jul 12, 2010 at 10:56 AM, Sander de Groot <s....@jdi.nl> wrote:
> Okay, I've created such a bundle and am definitely on the right track.
> But I do find the documentation a bit fuzzy, there are few examples to find.
>
> Do you have an examples of how to grant permissions? ( for example granting
> allpermission to the system bundle? )
> Or even better, do you have an example of how to limit a bundles' file
> permissions purely to one directory?
>
> This is what I have so far:
> / final ConditionalPermissionAdmin cpa =
> (ConditionalPermissionAdmin)
> context.getService(context.getServiceReference(ConditionalPermissionAdmin.class.getName()));
>
> final ConditionalPermissionUpdate condPermUpdate =
> cpa.newConditionalPermissionUpdate();
> final List<ConditionalPermissionInfo> permlist =
> condPermUpdate.getConditionalPermissionInfos();
>
> String webappdir = System.getProperty("jdi.webapps");
> System.out.println("WebAppDir: " + webappdir);
> permlist.add( // add permission to the list
> cpa.newConditionalPermissionInfo (
> "JDI-Webapplication-Permissions", // this should be
> unique, right? so how about reloading?
> new ConditionInfo[] {
> new
> ConditionInfo(BundleLocationCondition.class.getName(), new String[] {
> webappdir + "*"
> })
> },
> new PermissionInfo[] {
> new PermissionInfo(AllPermission.class.getName(), "",
> ""),
> new PermissionInfo(FilePermission.class.getName(),
> "/home/sander/", "*")
> },
> "deny"
> )
> );
> if ( condPermUpdate.commit() ) {
> System.out.println("Commit succeeded");
> } else {
> System.err.println("Commit failed");
> }/
>
> Questions that arose while creating the above snippet:
> - Should I remove permissions if my dedicated bundle is reloaded/stopped?
> - How can I remove permissions?
Just clear the condpermupdate list and commit it. Better yet, keep a
copy around and restore the previous permissions if you go away.
> - Is there a bundle which translates a textfile (properties/xml or
> whatsoever) so I won't have to hard-code the whole permission scheme?
You could have a look at the source code for chapter14 of the OSGi in
Action book. We have an example which uses a simple txt file and does
what you are asking for
(http://osgi-in-action.googlecode.com/svn/trunk/chapter14/combined-example
- look into the org.foo.policy bundle). In general, it sounds like
chapter14 might be interesting for you (the next meap update will have
a more advanced example where the policy bundle is explained too).
> And what about this dedicated bundle. What if this bundle is loaded after
> the bundles which require specific limitations? Can I do this with the
> starting levels or should I edit the config file so it will load this bundle
> first?
start level sound like a good idea.
> After some additional research I've found that the security features of
> Felix are not as mature as of Equinox.
Why not? It would be nice if you could give me some indication what
your research did find that makes you say that...
> It also seems that the security
> package provided at the felix download page won't start. Is this normal?
>
> / 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
Yes, its an extension bundle (they don't get started).
regards,
Karl
> On 07/09/2010 03:43 PM, François GOICHON wrote:
>>
>> What you have to do is to create a dedicated bundle that will play the
>> role of the permission agent.
>>
>> Within this bundle :
>> - get the permission admin service reference
>> - get the permission list
>> - grant allpermission to the system bundle (bundle 0), other Felix bundles
>> may need allpermission
>> - grant allpermission to this permission agent bundle
>> - then grant the different permissions you need to other bundles
>> - commit the permission list to the permission table
>>
>> Then, each time a permission check occurs, the security layer will be able
>> to determine whether each bundle providing each method on the call stack has
>> been granted this particular permission.
>>
>> Actually, as the permission administration is provided as a service, any
>> bundle having sufficient permissions can modify the permission table at any
>> time. So yes, you can therefore add/delete and commit new permissions when
>> catching some specific framework or service events.
>>
>> François
>>
>>
>> Sander de Groot wrote:
>>>
>>> Would it be possible to create a custom bundle which listens to other
>>> bundles' events and apply a specific permission scheme based on the for
>>> example bundlename/location or other properties? If so how can I enforce
>>> such a scheme on another bundle?
>>>
>>> Regards,
>>>
>>> Sander
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Karl Pauls <ka...@gmail.com>.
The bundlelocationcondition accepts a pattern which is matched against
of the location url of the bundle checked. You give something which
looks like a relative file path. That wont work. Try:
[org.osgi.service.condpermadmin.BundleLocationCondition "*/webapps/dist/*" ]
regards,
Karl
On Fri, Jul 16, 2010 at 5:57 PM, Sander de Groot <s....@jdi.nl> wrote:
>
>>>>> My case is as follows:
>>>>> I've got a large amount of bundles of which I want an unspecified
>>>>> amount
>>>>> of
>>>>> bundles from a specific directory to be limited in permissions.
>>>>>
>>>>> I'm currently using a policy file which represents PermissionInfo's and
>>>>> ConditionInfo's. I'm just not sure on how to use variables in the
>>>>> filters.
>>>>> It doesn't work but it does show want I'm aiming for.
>>>>>
>>>>> DENY {
>>>>> # Only apply the rule if the bundle comes from this dir
>>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>>> "${felix.root}/webapps/-" ]
>>>>> ( java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)"
>>>>> "*")
>>>>> } "Deny all access to files"
>>>>> ALLOW {
>>>>> # If the bundle does NOT come form this specific dir
>>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>>> "${felix.root}/webapps/-" "!" ]
>>>>> ( java.security.AllPermission "*" "*")
>>>>> } "Allow everything else"
>>>>>
>>>>> Rules:
>>>>> - Every bundle except bundles from directory '${felix.root}/webapps/-'
>>>>> have
>>>>> allpermissions
>>>>> - Bundles from '${felix.root}/webapps/-' only have access to dir:
>>>>> '/specific/path/${bundle.propertyX}/-' nothing more
>>>>>
>>>>> Is it possible to do this without creating new Condition classes? If
>>>>> not,
>>>>> what's the best way to get the requested result?
>>>>>
>>>>>
>>>>
>>>> This will not work:
>>>>
>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>> "${felix.root}/webapps/-" ]
>>>>
>>>> try:
>>>>
>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>> "${felix.root}/webapps/*" ]
>>>>
>>>>
>>>
>>> Why? I thought the only difference between - an * was the recursive
>>> aspect?
>>>
>>
>> Did you try it? The BundleLocationCondition is not a FilePermission so
>> why are you assuming it follows the same rules? Where in the spec does
>> it say it supports the same wildcards as filepermission?
>>
>
> Yes but there wasn't any difference because of the missing variable parser.
>
> I've now tried the following snippet:
> # The first rule which denies or allows is applied
> ALLOW {
> [ org.osgi.service.condpermadmin.BundleLocationCondition "webapps/dist/*"
> ]
> ( java.io.FilePermission "/home/sander/Downloads/-" "read,write")
> } "Allow access to a specific dir"
> DENY {
> [ org.osgi.service.condpermadmin.BundleLocationCondition "webapps/dist/*"
> ]
> ( java.io.FilePermission "/-" "read,write")
> } "Deny access to all other directories"
> ALLOW {
> ( java.security.AllPermission "*" "*")
> } "Allow everything else"
>
> but all bundles from webapps/dist/* are still able to write wherever they
> want...
> The snippet above follows the rules you told are applied (first rule
> counts): it should restrict bundles from webapp/dist only to
> /home/sander/Downloads/
>
>>>> (obviously, you can't use ${felix.root} out of the box...
>>>>
>>>>
>>>
>>> But I can use ${} as property-access system?
>>>
>>
>> Out of the box? No. You could extend the policy bundle to give you
>> some kind of property substitution but you have to do that yourself.
>>
>
> Okay.
>>>>
>>>> What is the problem you have? Its hard for me to see what could be
>>>> going wrong because of your "properties" i don't understand but are
>>>> you sure this is correct:
>>>>
>>>>
>>>
>>> My goal:
>>> All bundles loaded from a specific directory need to be constrained to
>>> one
>>> specific directory each. (So bundleX from that directory gets directory
>>> /var/bundles/bundleX/ and bundleY gets directory /var/bundles/bundleY/
>>> where
>>> everything else is denied)
>>>
>>
>> You probably want to write your own condition and or permission as i
>> don't see an easy way doing this with the provided
>> condition/permissions.
>>
>
> That's a shame. Not that I mind writing my own conditions but I don't seem
> how I could write my own file permission since this is integrated in Java
> itself or am I mistaken? I'm quite new to the security model of Java and
> don't know how it exactly works nor how OSGi integrates with the security
> model of Java. I've seen some presentations and read a few things about it
> and I intend to go through the source so I'll know what I'm talking about.
>
> I think I've got only two options left:
> 1. Hard-code everything
> 2. For each added bundle create a config item
>
> Do you have any (other) suggestion?
>
> Regards,
>
> Sander
>>
>> regards,
>>
>> Karl
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/16/10 11:57, Sander de Groot wrote:
>
>>>>> My case is as follows:
>>>>> I've got a large amount of bundles of which I want an
>>>>> unspecified amount
>>>>> of
>>>>> bundles from a specific directory to be limited in permissions.
>>>>>
>>>>> I'm currently using a policy file which represents
>>>>> PermissionInfo's and
>>>>> ConditionInfo's. I'm just not sure on how to use variables in the
>>>>> filters.
>>>>> It doesn't work but it does show want I'm aiming for.
>>>>>
>>>>> DENY {
>>>>> # Only apply the rule if the bundle comes from this dir
>>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>>> "${felix.root}/webapps/-" ]
>>>>> ( java.io.FilePermission
>>>>> "!(/specific/path/${bundle.propertyX}/-)"
>>>>> "*")
>>>>> } "Deny all access to files"
>>>>> ALLOW {
>>>>> # If the bundle does NOT come form this specific dir
>>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>>> "${felix.root}/webapps/-" "!" ]
>>>>> ( java.security.AllPermission "*" "*")
>>>>> } "Allow everything else"
>>>>>
>>>>> Rules:
>>>>> - Every bundle except bundles from directory
>>>>> '${felix.root}/webapps/-'
>>>>> have
>>>>> allpermissions
>>>>> - Bundles from '${felix.root}/webapps/-' only have access to dir:
>>>>> '/specific/path/${bundle.propertyX}/-' nothing more
>>>>>
>>>>> Is it possible to do this without creating new Condition classes?
>>>>> If not,
>>>>> what's the best way to get the requested result?
>>>>>
>>>> This will not work:
>>>>
>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>> "${felix.root}/webapps/-" ]
>>>>
>>>> try:
>>>>
>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>> "${felix.root}/webapps/*" ]
>>>>
>>> Why? I thought the only difference between - an * was the recursive
>>> aspect?
>> Did you try it? The BundleLocationCondition is not a FilePermission so
>> why are you assuming it follows the same rules? Where in the spec does
>> it say it supports the same wildcards as filepermission?
> Yes but there wasn't any difference because of the missing variable
> parser.
>
> I've now tried the following snippet:
> # The first rule which denies or allows is applied
> ALLOW {
> [ org.osgi.service.condpermadmin.BundleLocationCondition
> "webapps/dist/*" ]
> ( java.io.FilePermission "/home/sander/Downloads/-" "read,write")
> } "Allow access to a specific dir"
> DENY {
> [ org.osgi.service.condpermadmin.BundleLocationCondition
> "webapps/dist/*" ]
> ( java.io.FilePermission "/-" "read,write")
> } "Deny access to all other directories"
> ALLOW {
> ( java.security.AllPermission "*" "*")
> } "Allow everything else"
>
> but all bundles from webapps/dist/* are still able to write wherever
> they want...
Are you sure that's the correct location of your bundles? Perhaps you
should do an "lb -l" in the shell to verify that's your location string.
-> richard
> The snippet above follows the rules you told are applied (first rule
> counts): it should restrict bundles from webapp/dist only to
> /home/sander/Downloads/
>
>>>> (obviously, you can't use ${felix.root} out of the box...
>>>>
>>> But I can use ${} as property-access system?
>> Out of the box? No. You could extend the policy bundle to give you
>> some kind of property substitution but you have to do that yourself.
> Okay.
>>>> What is the problem you have? Its hard for me to see what could be
>>>> going wrong because of your "properties" i don't understand but are
>>>> you sure this is correct:
>>>>
>>> My goal:
>>> All bundles loaded from a specific directory need to be
>>> constrained to one
>>> specific directory each. (So bundleX from that directory gets directory
>>> /var/bundles/bundleX/ and bundleY gets directory
>>> /var/bundles/bundleY/ where
>>> everything else is denied)
>> You probably want to write your own condition and or permission as i
>> don't see an easy way doing this with the provided
>> condition/permissions.
>
> That's a shame. Not that I mind writing my own conditions but I don't
> seem how I could write my own file permission since this is integrated
> in Java itself or am I mistaken? I'm quite new to the security model
> of Java and don't know how it exactly works nor how OSGi integrates
> with the security model of Java. I've seen some presentations and read
> a few things about it and I intend to go through the source so I'll
> know what I'm talking about.
>
> I think I've got only two options left:
> 1. Hard-code everything
> 2. For each added bundle create a config item
>
> Do you have any (other) suggestion?
>
> Regards,
>
> Sander
>> regards,
>>
>> Karl
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
>>>> My case is as follows:
>>>> I've got a large amount of bundles of which I want an unspecified amount
>>>> of
>>>> bundles from a specific directory to be limited in permissions.
>>>>
>>>> I'm currently using a policy file which represents PermissionInfo's and
>>>> ConditionInfo's. I'm just not sure on how to use variables in the
>>>> filters.
>>>> It doesn't work but it does show want I'm aiming for.
>>>>
>>>> DENY {
>>>> # Only apply the rule if the bundle comes from this dir
>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>> "${felix.root}/webapps/-" ]
>>>> ( java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)"
>>>> "*")
>>>> } "Deny all access to files"
>>>> ALLOW {
>>>> # If the bundle does NOT come form this specific dir
>>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>>> "${felix.root}/webapps/-" "!" ]
>>>> ( java.security.AllPermission "*" "*")
>>>> } "Allow everything else"
>>>>
>>>> Rules:
>>>> - Every bundle except bundles from directory '${felix.root}/webapps/-'
>>>> have
>>>> allpermissions
>>>> - Bundles from '${felix.root}/webapps/-' only have access to dir:
>>>> '/specific/path/${bundle.propertyX}/-' nothing more
>>>>
>>>> Is it possible to do this without creating new Condition classes? If not,
>>>> what's the best way to get the requested result?
>>>>
>>>>
>>> This will not work:
>>>
>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>> "${felix.root}/webapps/-" ]
>>>
>>> try:
>>>
>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>> "${felix.root}/webapps/*" ]
>>>
>>>
>> Why? I thought the only difference between - an * was the recursive aspect?
>>
> Did you try it? The BundleLocationCondition is not a FilePermission so
> why are you assuming it follows the same rules? Where in the spec does
> it say it supports the same wildcards as filepermission?
>
Yes but there wasn't any difference because of the missing variable parser.
I've now tried the following snippet:
# The first rule which denies or allows is applied
ALLOW {
[ org.osgi.service.condpermadmin.BundleLocationCondition
"webapps/dist/*" ]
( java.io.FilePermission "/home/sander/Downloads/-" "read,write")
} "Allow access to a specific dir"
DENY {
[ org.osgi.service.condpermadmin.BundleLocationCondition
"webapps/dist/*" ]
( java.io.FilePermission "/-" "read,write")
} "Deny access to all other directories"
ALLOW {
( java.security.AllPermission "*" "*")
} "Allow everything else"
but all bundles from webapps/dist/* are still able to write wherever
they want...
The snippet above follows the rules you told are applied (first rule
counts): it should restrict bundles from webapp/dist only to
/home/sander/Downloads/
>>> (obviously, you can't use ${felix.root} out of the box...
>>>
>>>
>> But I can use ${} as property-access system?
>>
> Out of the box? No. You could extend the policy bundle to give you
> some kind of property substitution but you have to do that yourself.
>
Okay.
>>> What is the problem you have? Its hard for me to see what could be
>>> going wrong because of your "properties" i don't understand but are
>>> you sure this is correct:
>>>
>>>
>> My goal:
>> All bundles loaded from a specific directory need to be constrained to one
>> specific directory each. (So bundleX from that directory gets directory
>> /var/bundles/bundleX/ and bundleY gets directory /var/bundles/bundleY/ where
>> everything else is denied)
>>
> You probably want to write your own condition and or permission as i
> don't see an easy way doing this with the provided
> condition/permissions.
>
That's a shame. Not that I mind writing my own conditions but I don't
seem how I could write my own file permission since this is integrated
in Java itself or am I mistaken? I'm quite new to the security model of
Java and don't know how it exactly works nor how OSGi integrates with
the security model of Java. I've seen some presentations and read a few
things about it and I intend to go through the source so I'll know what
I'm talking about.
I think I've got only two options left:
1. Hard-code everything
2. For each added bundle create a config item
Do you have any (other) suggestion?
Regards,
Sander
> regards,
>
> Karl
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Karl Pauls <ka...@gmail.com>.
On Fri, Jul 16, 2010 at 9:04 AM, Sander de Groot <s....@jdi.nl> wrote:
> On 07/15/2010 10:45 PM, Karl Pauls wrote:
>>
>> On Wed, Jul 14, 2010 at 4:49 PM, Sander de Groot<s....@jdi.nl> wrote:
>>
>>>
>>> Despite of all my attempts I unfortunately still haven't solved my case.
>>> Its true that everything is denied by default, however is it also true
>>> that
>>> all relevant permissions have to be positive to allow the action?
>>>
>>
>> The order o the rules is important. If a rule is found which allows
>> the required permission and has all its conditions satisfied the
>> action is permitted (i.e., no other rules are evaluated) otherwise the
>> next rule is evaluated until there either is no more rule or we hit a
>> deny rule that matches the permission (a matching and satisfied deny
>> rule allways terminates).
>>
>
> Right, so it does not evaluate all rules but terminates at the first rule
> allowing or denying the specified action?
> (Or denies if there aren't any rules, right?)
yup.
> If this is so then we need to work top-to-bottom as in most specific to most
> generic? E.g. deny/allow /var/var1/var2 and then allow/deny /var/var1/* ?
>>>
>>> For instance: I can't say deny everything but allow 'this'.
>>>
>>
>> Right, but you can say allow this and deny everything (again, order is
>> significant).
>>
>>
>>>
>>> And if there are other conflicting permissions, OSGi will deny the
>>> action, right?
>>>
>>
>> Not shure what "other conflicting permissions" are in this case...
>>
>
> As you described there can't be conflicting permissions because OSGi stops
> evaluating as soon as it finds the first match.
> To clarify: conflicting permissions could be two permission rules which
> override each other (in other words: the first rule allows and the second
> denies)
>>
>>
>>>
>>> My case is as follows:
>>> I've got a large amount of bundles of which I want an unspecified amount
>>> of
>>> bundles from a specific directory to be limited in permissions.
>>>
>>> I'm currently using a policy file which represents PermissionInfo's and
>>> ConditionInfo's. I'm just not sure on how to use variables in the
>>> filters.
>>> It doesn't work but it does show want I'm aiming for.
>>>
>>> DENY {
>>> # Only apply the rule if the bundle comes from this dir
>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>> "${felix.root}/webapps/-" ]
>>> ( java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)"
>>> "*")
>>> } "Deny all access to files"
>>> ALLOW {
>>> # If the bundle does NOT come form this specific dir
>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>> "${felix.root}/webapps/-" "!" ]
>>> ( java.security.AllPermission "*" "*")
>>> } "Allow everything else"
>>>
>>> Rules:
>>> - Every bundle except bundles from directory '${felix.root}/webapps/-'
>>> have
>>> allpermissions
>>> - Bundles from '${felix.root}/webapps/-' only have access to dir:
>>> '/specific/path/${bundle.propertyX}/-' nothing more
>>>
>>> Is it possible to do this without creating new Condition classes? If not,
>>> what's the best way to get the requested result?
>>>
>>
>> This will not work:
>>
>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>> "${felix.root}/webapps/-" ]
>>
>> try:
>>
>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>> "${felix.root}/webapps/*" ]
>>
>
> Why? I thought the only difference between - an * was the recursive aspect?
Did you try it? The BundleLocationCondition is not a FilePermission so
why are you assuming it follows the same rules? Where in the spec does
it say it supports the same wildcards as filepermission?
>> (obviously, you can't use ${felix.root} out of the box...
>>
>
> But I can use ${} as property-access system?
Out of the box? No. You could extend the policy bundle to give you
some kind of property substitution but you have to do that yourself.
> Does it parse this kind of
> variables? And if so, what variables are available?
No.
>> What is the problem you have? Its hard for me to see what could be
>> going wrong because of your "properties" i don't understand but are
>> you sure this is correct:
>>
>
> My goal:
> All bundles loaded from a specific directory need to be constrained to one
> specific directory each. (So bundleX from that directory gets directory
> /var/bundles/bundleX/ and bundleY gets directory /var/bundles/bundleY/ where
> everything else is denied)
You probably want to write your own condition and or permission as i
don't see an easy way doing this with the provided
condition/permissions.
regards,
Karl
>> java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)" "*")
>>
>> Why is there a "!" in there and what is ${bundle.propertyX)?
>>
>
> The '!' is for inversion, just like in Java itself. What I'm trying to
> achieve with this rule: deny everything unless the directory is your 'home'
> directory.
>
> The property is for distinguishing the bundles. Since there will be a lot of
> bundles in that protected directory I can't make rules for every specific
> bundle.
>
> The propertyX is a specific property attached to the bundle in question. All
> permission requests will be coming from a specific bundle, I was hoping this
> bundle is known at evaluation time. The goal of this property thus is
> assigning a specific directory for a specific bundle (no shared directory).
> The property could be any property, like the bundle name, cannocial name or
> maybe a specific property defined runtime or in the manifest.
>>
>> regards,
>>
>> Karl
>>
>>>
>>> On 07/12/2010 11:57 AM, François GOICHON wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> For the practical part:
>>>>
>>>>>
>>>>> Do you have an examples of how to grant permissions? ( for example
>>>>> granting allpermission to the system bundle? )
>>>>>
>>>>
>>>> This is exactly what the sample code in the other thread does.
>>>>
>>>>>
>>>>> Or even better, do you have an example of how to limit a bundles' file
>>>>> permissions purely to one directory?
>>>>>
>>>>
>>>> permlist.add(cpa.newConditionalPermissionInfo(null,
>>>> new ConditionInfo[]{ new
>>>> ConditionInfo(BundleLocationCondition.class.getName(), new String[]{
>>>> "file:"
>>>> + webappdir + "*" }) },
>>>> new PermissionInfo[]{ new
>>>> PermissionInfo(FilePermission.class.getName(), "myDirectory/-",
>>>> "read,write") },
>>>> "allow"));
>>>>
>>>> In your example code you use the deny action but, by default, everything
>>>> is denied and you can add permissions. "Deny" can be used to restrict
>>>> existing permissions. For example, denying a specific permission in
>>>> allpermission, or allowing to read any file, but those from a specific
>>>> directory.
>>>>
>>>> Regards,
>>>>
>>>> François
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
On 07/15/2010 10:45 PM, Karl Pauls wrote:
> On Wed, Jul 14, 2010 at 4:49 PM, Sander de Groot<s....@jdi.nl> wrote:
>
>> Despite of all my attempts I unfortunately still haven't solved my case.
>> Its true that everything is denied by default, however is it also true that
>> all relevant permissions have to be positive to allow the action?
>>
> The order o the rules is important. If a rule is found which allows
> the required permission and has all its conditions satisfied the
> action is permitted (i.e., no other rules are evaluated) otherwise the
> next rule is evaluated until there either is no more rule or we hit a
> deny rule that matches the permission (a matching and satisfied deny
> rule allways terminates).
>
Right, so it does not evaluate all rules but terminates at the first
rule allowing or denying the specified action?
(Or denies if there aren't any rules, right?)
If this is so then we need to work top-to-bottom as in most specific to
most generic? E.g. deny/allow /var/var1/var2 and then allow/deny
/var/var1/* ?
>> For instance: I can't say deny everything but allow 'this'.
>>
> Right, but you can say allow this and deny everything (again, order is
> significant).
>
>
>> And if there are other conflicting permissions, OSGi will deny the action, right?
>>
> Not shure what "other conflicting permissions" are in this case...
>
As you described there can't be conflicting permissions because OSGi
stops evaluating as soon as it finds the first match.
To clarify: conflicting permissions could be two permission rules which
override each other (in other words: the first rule allows and the
second denies)
>
>> My case is as follows:
>> I've got a large amount of bundles of which I want an unspecified amount of
>> bundles from a specific directory to be limited in permissions.
>>
>> I'm currently using a policy file which represents PermissionInfo's and
>> ConditionInfo's. I'm just not sure on how to use variables in the filters.
>> It doesn't work but it does show want I'm aiming for.
>>
>> DENY {
>> # Only apply the rule if the bundle comes from this dir
>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>> "${felix.root}/webapps/-" ]
>> ( java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)" "*")
>> } "Deny all access to files"
>> ALLOW {
>> # If the bundle does NOT come form this specific dir
>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>> "${felix.root}/webapps/-" "!" ]
>> ( java.security.AllPermission "*" "*")
>> } "Allow everything else"
>>
>> Rules:
>> - Every bundle except bundles from directory '${felix.root}/webapps/-' have
>> allpermissions
>> - Bundles from '${felix.root}/webapps/-' only have access to dir:
>> '/specific/path/${bundle.propertyX}/-' nothing more
>>
>> Is it possible to do this without creating new Condition classes? If not,
>> what's the best way to get the requested result?
>>
> This will not work:
>
> [ org.osgi.service.condpermadmin.BundleLocationCondition
> "${felix.root}/webapps/-" ]
>
> try:
>
> [ org.osgi.service.condpermadmin.BundleLocationCondition
> "${felix.root}/webapps/*" ]
>
Why? I thought the only difference between - an * was the recursive aspect?
> (obviously, you can't use ${felix.root} out of the box...
>
But I can use ${} as property-access system? Does it parse this kind of
variables? And if so, what variables are available?
> What is the problem you have? Its hard for me to see what could be
> going wrong because of your "properties" i don't understand but are
> you sure this is correct:
>
My goal:
All bundles loaded from a specific directory need to be constrained
to one specific directory each. (So bundleX from that directory gets
directory /var/bundles/bundleX/ and bundleY gets directory
/var/bundles/bundleY/ where everything else is denied)
> java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)" "*")
>
> Why is there a "!" in there and what is ${bundle.propertyX)?
>
The '!' is for inversion, just like in Java itself. What I'm trying to
achieve with this rule: deny everything unless the directory is your
'home' directory.
The property is for distinguishing the bundles. Since there will be a
lot of bundles in that protected directory I can't make rules for every
specific bundle.
The propertyX is a specific property attached to the bundle in question.
All permission requests will be coming from a specific bundle, I was
hoping this bundle is known at evaluation time. The goal of this
property thus is assigning a specific directory for a specific bundle
(no shared directory). The property could be any property, like the
bundle name, cannocial name or maybe a specific property defined runtime
or in the manifest.
> regards,
>
> Karl
>
>> On 07/12/2010 11:57 AM, François GOICHON wrote:
>>
>>> Hi,
>>>
>>> For the practical part:
>>>
>>>> Do you have an examples of how to grant permissions? ( for example
>>>> granting allpermission to the system bundle? )
>>>>
>>> This is exactly what the sample code in the other thread does.
>>>
>>>> Or even better, do you have an example of how to limit a bundles' file
>>>> permissions purely to one directory?
>>>>
>>> permlist.add(cpa.newConditionalPermissionInfo(null,
>>> new ConditionInfo[]{ new
>>> ConditionInfo(BundleLocationCondition.class.getName(), new String[]{ "file:"
>>> + webappdir + "*" }) },
>>> new PermissionInfo[]{ new
>>> PermissionInfo(FilePermission.class.getName(), "myDirectory/-",
>>> "read,write") },
>>> "allow"));
>>>
>>> In your example code you use the deny action but, by default, everything
>>> is denied and you can add permissions. "Deny" can be used to restrict
>>> existing permissions. For example, denying a specific permission in
>>> allpermission, or allowing to read any file, but those from a specific
>>> directory.
>>>
>>> Regards,
>>>
>>> François
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Karl Pauls <ka...@gmail.com>.
On Wed, Jul 14, 2010 at 4:49 PM, Sander de Groot <s....@jdi.nl> wrote:
> Despite of all my attempts I unfortunately still haven't solved my case.
> Its true that everything is denied by default, however is it also true that
> all relevant permissions have to be positive to allow the action?
The order o the rules is important. If a rule is found which allows
the required permission and has all its conditions satisfied the
action is permitted (i.e., no other rules are evaluated) otherwise the
next rule is evaluated until there either is no more rule or we hit a
deny rule that matches the permission (a matching and satisfied deny
rule allways terminates).
> For instance: I can't say deny everything but allow 'this'.
Right, but you can say allow this and deny everything (again, order is
significant).
> And if there are other conflicting permissions, OSGi will deny the action, right?
Not shure what "other conflicting permissions" are in this case...
> My case is as follows:
> I've got a large amount of bundles of which I want an unspecified amount of
> bundles from a specific directory to be limited in permissions.
>
> I'm currently using a policy file which represents PermissionInfo's and
> ConditionInfo's. I'm just not sure on how to use variables in the filters.
> It doesn't work but it does show want I'm aiming for.
>
> DENY {
> # Only apply the rule if the bundle comes from this dir
> [ org.osgi.service.condpermadmin.BundleLocationCondition
> "${felix.root}/webapps/-" ]
> ( java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)" "*")
> } "Deny all access to files"
> ALLOW {
> # If the bundle does NOT come form this specific dir
> [ org.osgi.service.condpermadmin.BundleLocationCondition
> "${felix.root}/webapps/-" "!" ]
> ( java.security.AllPermission "*" "*")
> } "Allow everything else"
>
> Rules:
> - Every bundle except bundles from directory '${felix.root}/webapps/-' have
> allpermissions
> - Bundles from '${felix.root}/webapps/-' only have access to dir:
> '/specific/path/${bundle.propertyX}/-' nothing more
>
> Is it possible to do this without creating new Condition classes? If not,
> what's the best way to get the requested result?
This will not work:
[ org.osgi.service.condpermadmin.BundleLocationCondition
"${felix.root}/webapps/-" ]
try:
[ org.osgi.service.condpermadmin.BundleLocationCondition
"${felix.root}/webapps/*" ]
(obviously, you can't use ${felix.root} out of the box...
What is the problem you have? Its hard for me to see what could be
going wrong because of your "properties" i don't understand but are
you sure this is correct:
java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)" "*")
Why is there a "!" in there and what is ${bundle.propertyX)?
regards,
Karl
>
> On 07/12/2010 11:57 AM, François GOICHON wrote:
>>
>> Hi,
>>
>> For the practical part:
>>>
>>> Do you have an examples of how to grant permissions? ( for example
>>> granting allpermission to the system bundle? )
>>
>> This is exactly what the sample code in the other thread does.
>>>
>>> Or even better, do you have an example of how to limit a bundles' file
>>> permissions purely to one directory?
>>
>> permlist.add(cpa.newConditionalPermissionInfo(null,
>> new ConditionInfo[]{ new
>> ConditionInfo(BundleLocationCondition.class.getName(), new String[]{ "file:"
>> + webappdir + "*" }) },
>> new PermissionInfo[]{ new
>> PermissionInfo(FilePermission.class.getName(), "myDirectory/-",
>> "read,write") },
>> "allow"));
>>
>> In your example code you use the deny action but, by default, everything
>> is denied and you can add permissions. "Deny" can be used to restrict
>> existing permissions. For example, denying a specific permission in
>> allpermission, or allowing to read any file, but those from a specific
>> directory.
>>
>> Regards,
>>
>> François
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
Despite of all my attempts I unfortunately still haven't solved my case.
Its true that everything is denied by default, however is it also true
that all relevant permissions have to be positive to allow the action?
For instance: I can't say deny everything but allow 'this'. And if there
are other conflicting permissions, OSGi will deny the action, right?
My case is as follows:
I've got a large amount of bundles of which I want an unspecified
amount of bundles from a specific directory to be limited in permissions.
I'm currently using a policy file which represents PermissionInfo's and
ConditionInfo's. I'm just not sure on how to use variables in the
filters. It doesn't work but it does show want I'm aiming for.
DENY {
# Only apply the rule if the bundle comes from this dir
[ org.osgi.service.condpermadmin.BundleLocationCondition "${felix.root}/webapps/-" ]
( java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)" "*")
} "Deny all access to files"
ALLOW {
# If the bundle does NOT come form this specific dir
[ org.osgi.service.condpermadmin.BundleLocationCondition "${felix.root}/webapps/-" "!" ]
( java.security.AllPermission "*" "*")
} "Allow everything else"
Rules:
- Every bundle except bundles from directory '${felix.root}/webapps/-'
have allpermissions
- Bundles from '${felix.root}/webapps/-' only have access to dir:
'/specific/path/${bundle.propertyX}/-' nothing more
Is it possible to do this without creating new Condition classes? If
not, what's the best way to get the requested result?
On 07/12/2010 11:57 AM, François GOICHON wrote:
> Hi,
>
> For the practical part:
>> Do you have an examples of how to grant permissions? ( for example
>> granting allpermission to the system bundle? )
> This is exactly what the sample code in the other thread does.
>> Or even better, do you have an example of how to limit a bundles'
>> file permissions purely to one directory?
> permlist.add(cpa.newConditionalPermissionInfo(null,
> new ConditionInfo[]{ new
> ConditionInfo(BundleLocationCondition.class.getName(), new String[]{
> "file:" + webappdir + "*" }) },
> new PermissionInfo[]{ new
> PermissionInfo(FilePermission.class.getName(), "myDirectory/-",
> "read,write") },
> "allow"));
>
> In your example code you use the deny action but, by default,
> everything is denied and you can add permissions. "Deny" can be used
> to restrict existing permissions. For example, denying a specific
> permission in allpermission, or allowing to read any file, but those
> from a specific directory.
>
> Regards,
>
> François
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Bundle permissions
Posted by François GOICHON <fr...@insa-lyon.fr>.
Hi,
For the practical part:
> Do you have an examples of how to grant permissions? ( for example
> granting allpermission to the system bundle? )
This is exactly what the sample code in the other thread does.
> Or even better, do you have an example of how to limit a bundles' file
> permissions purely to one directory?
permlist.add(cpa.newConditionalPermissionInfo(null,
new ConditionInfo[]{ new
ConditionInfo(BundleLocationCondition.class.getName(), new String[]{
"file:" + webappdir + "*" }) },
new PermissionInfo[]{ new
PermissionInfo(FilePermission.class.getName(), "myDirectory/-",
"read,write") },
"allow"));
In your example code you use the deny action but, by default, everything
is denied and you can add permissions. "Deny" can be used to restrict
existing permissions. For example, denying a specific permission in
allpermission, or allowing to read any file, but those from a specific
directory.
Regards,
François
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
Okay, I've created such a bundle and am definitely on the right track.
But I do find the documentation a bit fuzzy, there are few examples to find.
Do you have an examples of how to grant permissions? ( for example
granting allpermission to the system bundle? )
Or even better, do you have an example of how to limit a bundles' file
permissions purely to one directory?
This is what I have so far:
/ final ConditionalPermissionAdmin cpa =
(ConditionalPermissionAdmin)
context.getService(context.getServiceReference(ConditionalPermissionAdmin.class.getName()));
final ConditionalPermissionUpdate condPermUpdate =
cpa.newConditionalPermissionUpdate();
final List<ConditionalPermissionInfo> permlist =
condPermUpdate.getConditionalPermissionInfos();
String webappdir = System.getProperty("jdi.webapps");
System.out.println("WebAppDir: " + webappdir);
permlist.add( // add permission to the list
cpa.newConditionalPermissionInfo (
"JDI-Webapplication-Permissions", // this should be
unique, right? so how about reloading?
new ConditionInfo[] {
new
ConditionInfo(BundleLocationCondition.class.getName(), new String[] {
webappdir + "*"
})
},
new PermissionInfo[] {
new PermissionInfo(AllPermission.class.getName(),
"", ""),
new PermissionInfo(FilePermission.class.getName(),
"/home/sander/", "*")
},
"deny"
)
);
if ( condPermUpdate.commit() ) {
System.out.println("Commit succeeded");
} else {
System.err.println("Commit failed");
}/
Questions that arose while creating the above snippet:
- Should I remove permissions if my dedicated bundle is reloaded/stopped?
- How can I remove permissions?
- Is there a bundle which translates a textfile (properties/xml or
whatsoever) so I won't have to hard-code the whole permission scheme?
And what about this dedicated bundle. What if this bundle is loaded
after the bundles which require specific limitations? Can I do this with
the starting levels or should I edit the config file so it will load
this bundle first?
After some additional research I've found that the security features of
Felix are not as mature as of Equinox. It also seems that the security
package provided at the felix download page won't start. Is this normal?
/ 7|Resolved | 1|Apache Felix Security Provider (1.2.0)/
On 07/09/2010 03:43 PM, François GOICHON wrote:
> What you have to do is to create a dedicated bundle that will play the
> role of the permission agent.
>
> Within this bundle :
> - get the permission admin service reference
> - get the permission list
> - grant allpermission to the system bundle (bundle 0), other Felix
> bundles may need allpermission
> - grant allpermission to this permission agent bundle
> - then grant the different permissions you need to other bundles
> - commit the permission list to the permission table
>
> Then, each time a permission check occurs, the security layer will be
> able to determine whether each bundle providing each method on the
> call stack has been granted this particular permission.
>
> Actually, as the permission administration is provided as a service,
> any bundle having sufficient permissions can modify the permission
> table at any time. So yes, you can therefore add/delete and commit new
> permissions when catching some specific framework or service events.
>
> François
>
>
> Sander de Groot wrote:
>> Would it be possible to create a custom bundle which listens to other
>> bundles' events and apply a specific permission scheme based on the
>> for example bundlename/location or other properties? If so how can I
>> enforce such a scheme on another bundle?
>>
>> Regards,
>>
>> Sander
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Bundle permissions
Posted by François GOICHON <fr...@insa-lyon.fr>.
What you have to do is to create a dedicated bundle that will play the
role of the permission agent.
Within this bundle :
- get the permission admin service reference
- get the permission list
- grant allpermission to the system bundle (bundle 0), other Felix
bundles may need allpermission
- grant allpermission to this permission agent bundle
- then grant the different permissions you need to other bundles
- commit the permission list to the permission table
Then, each time a permission check occurs, the security layer will be
able to determine whether each bundle providing each method on the call
stack has been granted this particular permission.
Actually, as the permission administration is provided as a service, any
bundle having sufficient permissions can modify the permission table at
any time. So yes, you can therefore add/delete and commit new
permissions when catching some specific framework or service events.
François
Sander de Groot wrote:
> Would it be possible to create a custom bundle which listens to other
> bundles' events and apply a specific permission scheme based on the
> for example bundlename/location or other properties? If so how can I
> enforce such a scheme on another bundle?
>
> Regards,
>
> Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Sander de Groot <s....@jdi.nl>.
Hi François,
Thanks, I hadn't seen that thread yet!
Indeed, the security layer is supposed to be able to handle my case.
The problem however is that I don't know how to do it let alone do it
the right way.
Your code:
final ConditionalPermissionAdmin cpa =
(ConditionalPermissionAdmin)
context.getService(context.getServiceReference(ConditionalPermissionAdmin.class.getName()));
final ConditionalPermissionUpdate condPermUpdate =
cpa.newConditionalPermissionUpdate(); final
List<ConditionalPermissionInfo> permlist =
condPermUpdate.getConditionalPermissionInfos();
permlist.add(cpa.newConditionalPermissionInfo(null,
new ConditionInfo[]{
new ConditionInfo(BundleLocationCondition.class.getName(),
new String[]{
context.getBundle(0).getLocation()
}
)
},
new PermissionInfo[]{
new PermissionInfo(AllPermission.class.getName(),"", "")
},
"allow"));
Definitely points me in the right direction.
Would it be possible to create a custom bundle which listens to other
bundles' events and apply a specific permission scheme based on the for
example bundlename/location or other properties? If so how can I enforce
such a scheme on another bundle?
Regards,
Sander
On 07/09/2010 02:07 PM, Goichon Francois wrote:
> Hi Sander,
>
>
> For the practical part, there is a start in this thread:
> http://www.mail-archive.com/users@felix.apache.org/msg07766.html
>
> As it is said, static permissions cannot handle the dynamic code that
> are bundles. OSGi introduced a security layer to perform those dynamic
> checks.
> As for static permissions, you can grant specific permissions
> (classical ones + some OSGi-specific permissions) to specific bundles
> (by code location or by bundle signer, as for static perms). You can
> also deny some permissions, which isn't possible with classical Java
> perms.
>
> In your case, you just have to grant permissions regarding their code
> location.
>
> Hope that helps,
>
> François
>
> Sander de Groot <s....@jdi.nl> a écrit :
>
>> Hi,
>>
>> After some research about security in OSGi I've found that it is
>> fairly difficult to find examples of how permissions are set.
>> The following resources proofed to be usefull:
>> - http://www.mail-archive.com/users@felix.apache.org/msg05090.html
>> - http://www.osgi.org/download/r4v41/r4.core.pdf
>> -
>> http://felix.apache.org/site/presentations.data/Building%20Secure%20OSGi%20Applications%20Workshop.pdf
>>
>>
>> Each of the links above contain a lot of theory but nothing practical
>> really.
>> My goal is fairly simple: I have got multiple bundles of a specific
>> category (webapplications) each of these webapplications have their
>> own 'home' directory. I want Felix to limit their file system access
>> only to this home directory and if necessary a few other specifically
>> assigned directories.
>>
>> My question: how can I achieve this permission scheme?
>> Related questions:
>> * Is specifying permissions limited to specific boundaries? (like:
>> bundlename, should the bundle specify its own permissions, etc.)
>> * How can I discriminate different 'categories'/'types' of bundles
>> * What about signing the bundles? Is this necessary, how to and why?
>>
>> Before I was used to create my own SecurityManager which would limit
>> the application programmatic. I don't mind using files or some other
>> way but I'd like to be in full control.
>>
>> Is this possible and so yes can you point me (or provide me) some
>> examples?
>>
>> Regards,
>>
>> Sander
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle permissions
Posted by Goichon Francois <fr...@insa-lyon.fr>.
Hi Sander,
For the practical part, there is a start in this thread:
http://www.mail-archive.com/users@felix.apache.org/msg07766.html
As it is said, static permissions cannot handle the dynamic code that
are bundles. OSGi introduced a security layer to perform those dynamic
checks.
As for static permissions, you can grant specific permissions
(classical ones + some OSGi-specific permissions) to specific bundles
(by code location or by bundle signer, as for static perms). You can
also deny some permissions, which isn't possible with classical Java
perms.
In your case, you just have to grant permissions regarding their code
location.
Hope that helps,
François
Sander de Groot <s....@jdi.nl> a écrit :
> Hi,
>
> After some research about security in OSGi I've found that it is
> fairly difficult to find examples of how permissions are set.
> The following resources proofed to be usefull:
> - http://www.mail-archive.com/users@felix.apache.org/msg05090.html
> - http://www.osgi.org/download/r4v41/r4.core.pdf
> -
> http://felix.apache.org/site/presentations.data/Building%20Secure%20OSGi%20Applications%20Workshop.pdf
>
> Each of the links above contain a lot of theory but nothing practical really.
> My goal is fairly simple: I have got multiple bundles of a specific
> category (webapplications) each of these webapplications have their
> own 'home' directory. I want Felix to limit their file system access
> only to this home directory and if necessary a few other
> specifically assigned directories.
>
> My question: how can I achieve this permission scheme?
> Related questions:
> * Is specifying permissions limited to specific boundaries? (like:
> bundlename, should the bundle specify its own permissions, etc.)
> * How can I discriminate different 'categories'/'types' of bundles
> * What about signing the bundles? Is this necessary, how to and why?
>
> Before I was used to create my own SecurityManager which would limit
> the application programmatic. I don't mind using files or some other
> way but I'd like to be in full control.
>
> Is this possible and so yes can you point me (or provide me) some examples?
>
> Regards,
>
> Sander
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org