Re: [Openjmx-devel] RMI adaptor and remote notifications

[B. <jer...@xt...>]

Carlos Quiroz wrote:

>[...]
>
>>>>If you serialize the filter it is uploaded to the agent, yes.
>>>>
>>>My scenario is with the agent running in some server and the client
>>>(Let's say a swing app) writes the filter above and adds a listener.
>>>Then the listener will be serialized and sent to the agent. 
>>>
>>Of course no !
>>If the listener is run in the server, how can the swing app be notified
>>of events ?
>>The listener is always remote (from server point of view), and runs in
>>the client.
>>
>Then you have a MBeanServer on the client side where you set a listener 
>listening for events where? on the local MBeans or the RemoteMBeans?
>In the later case the events are produced on the server and the question is 
>whether to filter them on the server or on the client
>Am I clear?
>
I do not understand why you need a MBeanServer on the client side. If a 
remote reference is given to the MBeanServer then it will simply call a 
remote method (so on the client side). Regarding your question about 
filtering at server or client side, I guess both would work. The lookup 
service in service handles that by saying that this is up to the client. 
So all notifications are sent and filtered on the client side. The 
problem with this scheme is that you should try to send some few times 
the notification (there might be a network congestion for example) if it 
does not work the first time. The call should be threaded too because we 
do not want to block the server while calling the client. If you choose 
to filter at server side, then it will be harder for a client to "change 
its mind" about filtering policies.

><snip>
>
>>No, the server already has it. It will be a pain to force the clients to
>>do all the above.
>>I set up a better implementation, client needs to do nothing :)
>>
>>>If
>>>you don't allow this then the code has to be introduced beforehand and
>>>is therefore trusted. Maybe you could clarify this but I think this
>>>scenario always calls for a security manager
>>>
>>Not necessarly, see above.
>>We serialize known and trusted classes, client code is transparent. The
>>proxy pattern.
>>
>Doesn't this problem extend to the MLet service. It is actually downloading 
>jars and executing foreign code. My vision is that this ALWAYS call for a 
>SecurityManager. Or maybe MLet code should be run in a sandbox
>
Like for a lot of RMI application, I think that OpenJMX should run under 
a security manager (the RMI one would be fine) and a well-secured policy 
file.

>>>My point is that this problem is much broader than only the 
>>>filter. You
>>>could upload a MBean which does something similar
>>>
>>Yes, the problem is broader. Once you add adaptors, you need the Agent
>>run under security manager, since by design you can create MBeans from a
>>client.
>>
>Again, to create MBeans remotely you need to have the class definition on the 
>server either beforehand (Then it can be considerd trusted) or later via MLet 
>in which case there should be a protection.
>
We know from where are coming classes (with the help of codebase 
annotations) so why not simply add a sort of firewall? We could say that 
we accept for examples classes coming from location A and B.

> Of course you can assume that if 
>somebody can create MLets in the server then the access is controlled and 
>trusted
>
This is another option although the previous item might enforce security.



Jerome.