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