[Design the new POJO MicroContainer] - JBMICROCONT-385 - Privileged actions for GenericBeanFactory.
by adrian@jboss.org
I like the way you create a blocker issue when you haven't even discussed it in the
forums. :-)
It could just as easily have been an aop or ejb3 problem since it is they
that are trying to createBean() and the caller has no rights.
In fact, the initial issue is definetly an MC problem.
It shouldn't be trying to use the TCL at all which is where it is failing.
The reason it is trying to use it, is because the caller
doesn't have the getClassLoader permission to retrieve the classloader
from the KernelControllerContext.
So that should be in a privileged action.
But equally, I've gone beyond that basic fix, since in my opionion, the
createBean() should run under the privileges of whoever registered the
GenericBeanFactory in the MC.
So I've changed it to do that as well.
This required a change to AbstractKernelControllerContext::getAccessControlContext()
to make it public.
Equally, since that information should be protected against misuse,
I've required the caller to have
new SecurityPermission("getAccessControlContext");
I'm not sure if that is the correct permission or whether this should be
one of the fine grained permissions described on a different thread.
You can find the test(s) for these in
org.jboss.test.kernel.controller.test.GenericBeanFactoryAccessControlTestCase
The first test registers a GenericBeanFactory in a context that
can access the System properties. It shows the constructor
can still do that when you use createBean().
It also tests that createBean() uses the correct classloader (not the TCL).
The second test is similar, except the context registering the GBF
doesn't have the rights to get the system properties.
NOTE: Just because createBean() now restores your privileges from
GBF registration time, that doesn't mean you shouldn't use privilege blocks.
Who knows in what security context somebody will create a GBF for your bean? :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190149#4190149
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190149
17 years, 4 months
[Design of JBoss jBPM] - Re: API first cut available for jBPM3
by kukeltje
"thomas.diesler(a)jboss.com" wrote : ProcessInstance => Process
|
| In Java an object instance is commonly called Foo not FooInstance. The standard talks about an "instance of a Process" rather than a ProcessInstance
|
|
Hmm... semantics? imo this is not about the intstance of a Process (Java) object but of an instance of the Process as a business object as compared to the definition. Your argument is kind of still valid than (about removing the Instance part) just in another context. Otoh, it makes it kind of clear that it is *not* a definition.
"thomas.diesler(a)jboss.com" wrote : Tokens may have a parent child relationship, Process' do not.
| A Process can be started, a Token cannot.
| A Process has structure (i.e. child Nodes), a Token has not.
| What about the relation between processes and subprocesses? Are those only visible via the definition? It might make sense to have a method in the api that says Process.hasRunningChildProcesses() or something like that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190134#4190134
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190134
17 years, 4 months