On Mon, Jul 12, 2010 at 2:33 PM, Sander de Groot <[email protected]> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Karl Pauls [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
