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<[email protected]>  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<[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]





---------------------------------------------------------------------
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]

Reply via email to