Post by Carlos Quiroz[...]
Post by Bordet, SimonePost by Carlos QuirozPost by Bordet, SimoneIf 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.
Post by Carlos Quiroz<snip>
Post by Bordet, SimoneNo, 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 :)
Post by Carlos QuirozIf
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.
Post by Carlos QuirozPost by Bordet, SimonePost by Carlos QuirozMy 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.
Post by Carlos QuirozOf 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.