You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Karl Pauls (JIRA)" <ji...@apache.org> on 2008/11/27 15:42:44 UTC
[jira] Issue Comment Edited: (FELIX-837) Setting the
SecurityManager in a bundle generate an infinite loop
[ https://issues.apache.org/jira/browse/FELIX-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651360#action_12651360 ]
karlpauls edited comment on FELIX-837 at 11/27/08 6:41 AM:
------------------------------------------------------------
First, let me say that I don't think specifying a security manager inside a bundle is a good idea. It doesn't seem to be very portable and it should be up to the framework to specify the security manager anyways. Second, specifying an RMISecurityManager at run time does require you to start the jvm with a -Djava.security.policy=<path-to-policy> property. Otherwise, you will not be able to do much after you set the security manager.
That said, we do have an issue. It should be possible to set a security manager dynamically but the problem is that our URLHandlers does need to do some privileged stuff which triggers a load of the default policy. That in turn creates a URL to the policy file which gets us in the mentioned loop. I don't have a good idea how to avoid that atm and am not sure its possible at all. Need to think about it some more.
However, there are a couple of workarounds:
1) disable URLHandlers if you don't need it (i.e., -Dfelix.service.urlhandlers=false). In your case you would although want to specific a valid policy file as mentioned above.
2) set a custom Policy that doesn't create a URL before you set the security manager (then you wouldn't need to specify a policy on startup either) e.g.,
Policy.setPolicy(new Policy()
{
public void refresh(){}
public PermissionCollection getPermissions(CodeSource source)
{
return new PermissionCollection()
{
public void add(Permission perm){}
public boolean implies(Permission perm){return true;}
public Enumeration elements()
{
return new Enumeration()
{
private volatile boolean more=true;
public Object nextElement()
{
more = false;
return new AllPermission();
}
public boolean hasMoreElements()
{
return more;
}
};
}
};
}
});
System.setSecurityManager(new RMISecurityManager());
Please let me know if one of the workarounds is good for you.
was (Author: karlpauls):
First, let me say that I don't think specifying a security manager inside a bundle is a good idea. It doesn't seem to be very portable and it should be up to the framework to specify the security manager anyways. Second, specifying an RMISecurityManager at run time does require you to start the jvm with a -Djava.security.policy=<path-to-policy> property. Otherwise, you will not be able to do much after you set the security manager.
That said, we do have an issue. It should be possible to set a security manager dynamically but the problem is that our URLHandlers does need to do some privileged stuff which triggers a load of the default policy. That in turn creates a URL to the policy file which gets us in the mentioned loop. I don't have a good idea how to avoid that atm and am not sure its possible at all. Need to think about it some more.
However, there are a couple of workarounds:
1) disable URLHandlers if you don't need it (i.e., -Dfelix.service.urlhandlers=false). In your case you would although want to specific a valid policy file as mentioned above.
2) set a custom Policy that doesn't create a URL before you set the security manager (then you wouldn't need to specify a policy on startup either) e.g.,
Policy.setPolicy(new Policy()
{
public void refresh(){}
public PermissionCollection getPermissions(CodeSource source)
{
return new PermissionCollection()
{
public void add(Permission perm){}
public boolean implies(Permission perm){return true;}
public Enumeration elements()
{
return new Enumeration()
{
private volatile boolean more=true;
public Object nextElement()
{
more = false;
return new AllPermission();
}
public boolean hasMoreElements()
{
return more;
}
};
}
};
}
});
System.setSecurityManager(new RMISecurityManager());
> Setting the SecurityManager in a bundle generate an infinite loop
> -----------------------------------------------------------------
>
> Key: FELIX-837
> URL: https://issues.apache.org/jira/browse/FELIX-837
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: felix-1.4.0
> Reporter: Loris Bouzonnet
> Assignee: Karl Pauls
> Priority: Minor
> Fix For: felix-1.4.1
>
> Attachments: sm-test.zip
>
>
> Since Felix 1.4.0, each method invocation is now check in the class SecureAction. When we DON'T set the security manager as argument of the command line and a started bundle tries to set this one, we always get an infinite loop:
> at java.net.URL.<init>(URL.java:413)
> at sun.security.provider.PolicyFile$3.run(PolicyFile.java:676)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.provider.PolicyFile.initStaticPolicy(PolicyFile.java:617)
> at sun.security.provider.PolicyFile.<init>(PolicyFile.java:314)
> at java.security.Policy.getPolicyNoCheck(Policy.java:145)
> at java.security.ProtectionDomain.implies(ProtectionDomain.java:195)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:249)
> at java.security.AccessController.checkPermission(AccessController.java:427)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
> at org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1123)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:754)
> at org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:400)
> at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:267)
> at java.net.URL.<init>(URL.java:596)
> at java.net.URL.<init>(URL.java:464)
> at java.net.URL.<init>(URL.java:413)
> at sun.security.provider.PolicyFile$3.run(PolicyFile.java:676)
> ... until a stack overflow.
> To reproduce it, just start the attached bundle that does:
> System.setSecurityManager(new RMISecurityManager());
> URL wantBug = new URL("http://felix.apache.org");
> System.out.println("I want a bug: " + wantBug.toExternalForm());
> If the security manager is set in the command line, there is no bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.