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