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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
