[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Beta release imminent
by anil.saldhana@jboss.com
| grant codeBase "file:${build.home}/api/target/test/classes/-"
| {
| permission java.lang.RuntimePermission "modifyThread"; // for executor control
| };
|
| grant codeBase "file:${build.home}/core/target/test/classes/-"
| {
| permission java.lang.RuntimePermission "modifyThread"; // for executor control
| permission org.jboss.remoting.EndpointPermission "createRequestHandler";
| permission org.jboss.remoting.EndpointPermission "createClient";
| };
|
| grant codeBase "file:${build.home}/protocol/basic/target/test/classes/-"
| {
| permission java.lang.RuntimePermission "modifyThread"; // for executor control
| permission java.net.SocketPermission "*:*", "accept, connect, resolve";
| permission org.jboss.remoting.EndpointPermission "createRequestHandler";
| permission org.jboss.remoting.EndpointPermission "createClient";
| };
|
| grant codeBase "file:${build.home}/protocol/multiplex/target/test/classes/-"
| {
| permission java.lang.RuntimePermission "modifyThread"; // for executor control
| permission java.net.SocketPermission "*:*", "accept, connect, resolve";
| permission org.jboss.remoting.EndpointPermission "createRequestHandler";
| permission org.jboss.remoting.EndpointPermission "createClient";
| };
|
|
I think the permissions assigned to the tests are pretty lenient. Mainly the socket perm.
But since this is remoting, I cannot comment.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189531#4189531
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189531
17 years, 4 months
[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149
by scott.stark@jboss.org
So you have org.jboss.aspect.TCCL which sets the TCCL that is applied a call to Thread.setContextClassLoader that uses a privileged block to isolate the caller. So the first issue is that this cannot be a mechanism to circumvent the security check for calling setContextClassLoader, so the application of the aspect has to have a security check that applies to codebase where the aspect is being applied. I'm sure the aop layer does not make this check today.
I still think the generated bytecode in the vfsmemory: location also has a permission that is inherited from the aspect codebase so that you know what an aspect is allowed to do. Unless I have granted the setContextClassLoader to the aspect, I'm not going to be able to apply it to some call context to change the caller's ability to perform a privileged operation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189501#4189501
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189501
17 years, 4 months