MBeanServer -> MBean interceptors

[simone]

Hi [long],

so I was playing with the idea of MBeanServer -> MBean interceptors, and actually found that they're quite useful :)

In "another implementation" (which I cannot mention because otherwise Marc will bust me) you can have the code details ]:)

My idea is this one: we intercept calls that may end up in invoking the MBean instance, that is:
- add/removeNotificationListener
- MBeanRegistration Methods
- set/getAttribute(s) + invoke
- instantiate
- getMBeanInfo

The MBeanServerInterceptor interface will have a bunch of methods instead of the de-typed "invoke(Invocation)" one, to avoid reflection slowness. Interceptors and the configurator of them are MBeans registered in the MBeanServer itself

One use of this interceptors will be the context classloader setting, that now is not factored apart.

But there is another interesting use I was discussing yesterday with JSR 160 people.

Imagine this example:

MBeanA in mbeana.jar
MBeanB in mbeanb.jar
jmx.jar with the implementation

Now MBeanB writes to files. When run under a security manager, this is a restricted operation, so you need this policy file (pseudo-syntax):

grant codebase "jmx.jar" {AllPermission};
grant codebase "mbeanb.jar" {FilePermission <<ALL FILES>>, "rwdx"};

Ok, now from MBeanA you want to call MBeanB, so the stack is:

MBeanA
MBeanServer.invoke
MBeanB

which means that also MBeanA will need MBeanB's permissions.

So what happens if MBeanA talks to 10 different MBeans ? That it will need the union of all their permissions. Bad.

But we can have an MBeanServerInterceptor to take care of this problem :)

Its task is this:
- check a MBeanAccessPermission
- invoke the next interceptor in a privileged block

MBeanAccessPermission takes an object name as parameter and its meaning is: "can I access the MBean with the specified object name, regardless of the operation I will do there ?", or better yet, "can I invoke the MBean with the specified object name in a privileged block ?"

If I cannot, the interceptor will throw a SecurityException.

The stack will be:

MBeanA
MBeanServer.invoke
AccessController.doPrivileged
MBeanB

In this case MBeanA only need the permission to access MBeanB, so the policy file will be:

grant codebase "jmx.jar" {AllPermission};
grant codebase "mbeanb.jar" {FilePermission <<ALL FILES>>, "rwdx"};
grant codebase "mbeana.jar" {MBeanAccessPermission, "MBean:type=B"};

Want to access 10 MBeans ?

grant codebase "mbeana.jar" {MBeanAccessPermission, "MBean:*"};

Comments are welcome.

Regards

Simon

[squirest]

> In "another implementation" (which I cannot mention
> because otherwise Marc will bust me) you can have the
> code details ]:)

:D

> Comments are welcome.

At first glance I like it.

I think it neatly sidesteps issues which I came across when trying to use per-mbean interceptors to facilitate what was actually per-agent behaviour.

While agent-level security is an extremely good fit for this, there isn't all that much left which is appropriate for agent-level interceptors.

I'm probably stating the obvious but it would be best to avoid a situtation where a ton of interceptors have been configured, each looking up the ObjectName to see if this call is destined for one of the few mbeans it's really interested in.

As such I think per-mbean interceptors are still required right?

Trev

[simone]

> At first glance I like it.
>
> I think it neatly sidesteps issues which I came
> across when trying to use per-mbean interceptors to
> facilitate what was actually per-agent behaviour.

Yes, that's exactly their use.

> While agent-level security is an extremely good fit
> for this, there isn't all that much left which is
> appropriate for agent-level interceptors.

- security
- context classloader
- logging of mbean access (and eventual notifications of the accesses)

At a first glance I also thought "ok, good for the context classloader, but something else ?"

Then it came the security one...

Well, who knows ?

> I'm probably stating the obvious but it would be best
> to avoid a situtation where a ton of interceptors
> have been configured, each looking up the ObjectName
> to see if this call is destined for one of the few
> mbeans it's really interested in.

Why tons of interceptors ?
Just one, 10 lines of code, all the rest is done by the Java security model
Furthermore, no need to register them as MBeans, if you don't want to configure them

> As such I think per-mbean interceptors are still
> required right?

Uhm don't know what you exactly mean by per-mbean interceptor, but IMHO per-MBean interceptor must be coded outside the JMX agent, in the MBean itself, so that it's portable to another JMX implementation.
Isn't this what the XMBean is all about, though I did not looked at it yet ?

Simon

[squirest]

> - security
> - context classloader
> - logging of mbean access (and eventual notifications
> of the accesses)

Ok, security/logging yes. Context classloader troubles me WRT invokes and attributes. Maybe you could clear it up.

It's not enough to push a context classloader onto the Thread is it?. If the interceptor doesn't also marshal arguments and return values between the loaders there will be problems right?

> Why tons of interceptors ?
> Just one, 10 lines of code, all the rest is done by
> the Java security model

Don't sweat it. It was a comment that popped into my head driven by the fact that the API I think you are suggesting encourages functional/target intersections to decide whether or not to manipulate the intercepted call.

See below:

> Uhm don't know what you exactly mean by per-mbean
> interceptor, but IMHO per-MBean interceptor must be
> coded outside the JMX agent, in the MBean
> itself, so that it's portable to another JMX
> implementation.

Exactly. I was only wondering whether you were intending to use serverinterceptors to handle the intersections I refer to above or whether you thought per-mbean interceptors have a place.

Trev