Menu
▾
▴
openjmx-devel
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 13:13:06
|
> -----Original Message----- > From: Bordet, Simone [mailto:Sim...@co...] > Sent: 30 January 2002 15:10 > To: OpenJMX-Dev (E-mail) > Subject: [Openjmx-devel] RMI adaptor and remote notifications >=20 > Hi, Hi >=20 > I've added possibility to receive in the client notifications from a > remote MBeanServer. >=20 > Listeners are always remote, but NotificationFilters may be serialized to > the server and be executed there. >=20 > Is there any preference on how filters must be treated ? >=20 > 1) Always as remote, like listeners (will be executed in the client) > 2) Always serialized to the server (will executed in the server) I'm sure this is a lot more Network efficient > 3) try first with 2, if fails fall through to 1 When may this happen? >=20 > Any other opinion ? >=20 > Simon >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 13:16:44
|
Hi, > > I've added possibility to receive in the client notifications from a > > remote MBeanServer. > >=20 > > Listeners are always remote, but NotificationFilters may be=20 > serialized > to > > the server and be executed there. > >=20 > > Is there any preference on how filters must be treated ? > >=20 > > 1) Always as remote, like listeners (will be executed in the client) > > 2) Always serialized to the server (will executed in the server) > I'm sure this is a lot more Network efficient >=20 > > 3) try first with 2, if fails fall through to 1 > When may this happen? When filter implementation is not serializable. Simon |
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 13:17:49
|
> -----Original Message----- > From: Bordet, Simone [mailto:Sim...@co...] > Sent: 30 January 2002 15:16 > To: Carlos Quiroz; OpenJMX-Dev (E-mail) > Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications >=20 > Hi, >=20 > > > I've added possibility to receive in the client notifications from a > > > remote MBeanServer. > > > > > > Listeners are always remote, but NotificationFilters may be > > serialized > > to > > > the server and be executed there. > > > > > > Is there any preference on how filters must be treated ? > > > > > > 1) Always as remote, like listeners (will be executed in the client) > > > 2) Always serialized to the server (will executed in the server) > > I'm sure this is a lot more Network efficient > > > > > 3) try first with 2, if fails fall through to 1 > > When may this happen? >=20 > When filter implementation is not serializable. Ok, then my vote is for 3 >=20 > Simon |
|
From: Bronwen C. <Bro...@ja...> - 2002-01-30 13:20:59
|
Agreed 3 sounds the best Bronwen > -----Original Message----- > From: Carlos Quiroz [mailto:Car...@ge...] > Sent: 30 January 2002 13:16 > To: OpenJMX-Dev (E-mail) > Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications > > > > > > -----Original Message----- > > From: Bordet, Simone [mailto:Sim...@co...] > > Sent: 30 January 2002 15:16 > > To: Carlos Quiroz; OpenJMX-Dev (E-mail) > > Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications > > > > Hi, > > > > > > I've added possibility to receive in the client > notifications from > a > > > > remote MBeanServer. > > > > > > > > Listeners are always remote, but NotificationFilters may be > > > serialized > > > to > > > > the server and be executed there. > > > > > > > > Is there any preference on how filters must be treated ? > > > > > > > > 1) Always as remote, like listeners (will be executed in the > client) > > > > 2) Always serialized to the server (will executed in the server) > > > I'm sure this is a lot more Network efficient > > > > > > > 3) try first with 2, if fails fall through to 1 > > > When may this happen? > > > > When filter implementation is not serializable. > Ok, then my vote is for 3 > > > > > Simon > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 13:26:38
|
Hi,
> > > > I've added possibility to receive in the client=20
> notifications from
> a
> > > > remote MBeanServer.
> > > >
> > > > Listeners are always remote, but NotificationFilters may be
> > > serialized
> > > to
> > > > the server and be executed there.
> > > >
> > > > Is there any preference on how filters must be treated ?
> > > >
> > > > 1) Always as remote, like listeners (will be executed in the
> client)
> > > > 2) Always serialized to the server (will executed in the server)
> > > I'm sure this is a lot more Network efficient
> > >
> > > > 3) try first with 2, if fails fall through to 1
> > > When may this happen?
> >=20
> > When filter implementation is not serializable.
> Ok, then my vote is for 3
Eh, not that simple.
Look at this filter
class MyFilter implements NotificationFilter=20
{
public boolean isNotificationEnabled(Notification n)=20
{
List l =3D MBeanServerFactory.findMBeanServer(null);
for (Iterator i =3D l.iterator(); i.hasNext();)=20
{
MBeanServer s =3D (MBeanServer)i.next();
MBeanServerFactory.releaseMBeanServer(s);
}
return true;
}
}
This will force us to run the agent always under security manager...
We want to leave open this security hole, and go for a simpler
implementation ?
We want many remote calls for each notification ?
Mumble, mumble...
Simon
|
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 13:32:14
|
> -----Original Message-----
> From: Bordet, Simone [mailto:Sim...@co...]
> Sent: 30 January 2002 15:26
> To: OpenJMX-Dev (E-mail)
> Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications
>=20
> Hi,
>=20
> > > > > I've added possibility to receive in the client
> > notifications from
> > a
> > > > > remote MBeanServer.
> > > > >
> > > > > Listeners are always remote, but NotificationFilters may be
> > > > serialized
> > > > to
> > > > > the server and be executed there.
> > > > >
> > > > > Is there any preference on how filters must be treated ?
> > > > >
> > > > > 1) Always as remote, like listeners (will be executed in the
> > client)
> > > > > 2) Always serialized to the server (will executed in the
server)
> > > > I'm sure this is a lot more Network efficient
> > > >
> > > > > 3) try first with 2, if fails fall through to 1
> > > > When may this happen?
> > >
> > > When filter implementation is not serializable.
> > Ok, then my vote is for 3
>=20
> Eh, not that simple.
>=20
> Look at this filter
>=20
> class MyFilter implements NotificationFilter
> {
> public boolean isNotificationEnabled(Notification n)
> {
> List l =3D MBeanServerFactory.findMBeanServer(null);
> for (Iterator i =3D l.iterator(); i.hasNext();)
> {
> MBeanServer s =3D (MBeanServer)i.next();
> MBeanServerFactory.releaseMBeanServer(s);
> }
> return true;
> }
> }
Would you upload this code to the Agent? How using for instance a web
server in the codebase?
I think this will be always a problem using RMI, and you would normally
run it with a security manager. There are many other things that can be
done if you are uploading code (spyware, viruses, etc...)
>=20
> This will force us to run the agent always under security manager...
>=20
> We want to leave open this security hole, and go for a simpler
> implementation ?
>=20
> We want many remote calls for each notification ?
>=20
> Mumble, mumble...
>=20
> Simon
>=20
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 13:38:23
|
Hi,
> > Look at this filter
> >=20
> > class MyFilter implements NotificationFilter
> > {
> > public boolean isNotificationEnabled(Notification n)
> > {
> > List l =3D MBeanServerFactory.findMBeanServer(null);
> > for (Iterator i =3D l.iterator(); i.hasNext();)
> > {
> > MBeanServer s =3D (MBeanServer)i.next();
> > MBeanServerFactory.releaseMBeanServer(s);
> > }
> > return true;
> > }
> > }
> Would you upload this code to the Agent?=20
If you serialize the filter it is uploaded to the agent, yes.
> How using for instance a web
> server in the codebase?
Not following.
> I think this will be always a problem using RMI, and you=20
> would normally
> run it with a security manager.=20
No, if the filter is remote.
> There are many other things=20
> that can be
> done if you are uploading code (spyware, viruses, etc...)
Yes, so ?
Remote filters ?
Simon
|
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 13:46:52
|
> -----Original Message-----
> From: Bordet, Simone [mailto:Sim...@co...]
> Sent: 30 January 2002 15:38
> To: OpenJMX-Dev (E-mail)
> Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications
>=20
> Hi,
>=20
> > > Look at this filter
> > >
> > > class MyFilter implements NotificationFilter
> > > {
> > > public boolean isNotificationEnabled(Notification n)
> > > {
> > > List l =3D MBeanServerFactory.findMBeanServer(null);
> > > for (Iterator i =3D l.iterator(); i.hasNext();)
> > > {
> > > MBeanServer s =3D (MBeanServer)i.next();
> > > MBeanServerFactory.releaseMBeanServer(s);
> > > }
> > > return true;
> > > }
> > > }
> > Would you upload this code to the Agent?
>=20
> 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. Are we
talking about the same idea?
>=20
> > How using for instance a web
> > server in the codebase?
>=20
> Not following.
Obviously you cannot just send a serialized object to the agent and
expect it to know how to deserialize it and execute. You have to also
download the class definition which may be available in a web server. 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
>=20
> > I think this will be always a problem using RMI, and you
> > would normally
> > run it with a security manager.
>=20
> No, if the filter is remote.
>=20
> > There are many other things
> > that can be
> > done if you are uploading code (spyware, viruses, etc...)
>=20
> Yes, so ?
My point is that this problem is much broader than only the filter. You
could upload a MBean which does something similar
>=20
> Remote filters ?
>=20
> Simon
>=20
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 14:04:54
|
Hi, > > 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.=20 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. > Are we talking about the same idea? > >=20 > > > How using for instance a web > > > server in the codebase? > >=20 > > Not following. > > Obviously you cannot just send a serialized object to the agent and > expect it to know how to deserialize it and execute.=20 > You have to also > download the class definition which may be available in a web=20 > server.=20 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. > My point is that this problem is much broader than only the=20 > 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. I just wanted here to know the opinion on filters, but the security issue must be faced. Fortunately I know something about it :) Simon |
|
From: Carlos Q. <car...@ge...> - 2002-01-31 09:46:28
|
>Hi, Hi Let's continue this discussion > >> > 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.=20 > >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=20 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=20 whether to filter them on the server or on the client Am I clear? <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 downloadi= ng=20 jars and executing foreign code. My vision is that this ALWAYS call for a= =20 SecurityManager. Or maybe MLet code should be run in a sandbox > >> My point is that this problem is much broader than only the=20 >> 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=20 server either beforehand (Then it can be considerd trusted) or later via = MLet=20 in which case there should be a protection. Of course you can assume that= if=20 somebody can create MLets in the server then the access is controlled and= =20 trusted > >I just wanted here to know the opinion on filters, but the security >issue must be faced. >Fortunately I know something about it :) Good ;-) Perhaps you should take a closer look to the Http/SSL Adapters, there may= be=20 risks there too. > >Simon > |
|
From: B. <jer...@xt...> - 2002-01-31 10:07:51
|
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. |
|
From: B. <jer...@xt...> - 2002-01-31 10:11:59
|
J=E9r=F4me BERNARD wrote: [...] > The lookup service in service handles that by saying that this is up=20 > to the client. I meant the lookup service in Jini. Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-31 10:11:07
|
Hi, > >> > 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=20 > listener. > >> Then the listener will be serialized and sent to the agent.=20 > > > >Of course no ! > >If the listener is run in the server, how can the swing app=20 > be notified > >of events ? > >The listener is always remote (from server point of view),=20 > and runs in > >the client. > Then you have a MBeanServer on the client side where you set=20 > a listener=20 > listening for events where? on the local MBeans or the RemoteMBeans? > In the later case the events are produced on the server and=20 > the question is=20 > whether to filter them on the server or on the client > Am I clear? No. On Client you have client application and the RMI connector. On Server you have RMI adaptor and MBeanServer, with your MBeans. One of your MBean emit events. MBeanServer dispatches events to = listeners. From client you register a remote listener. This listener is "remote" = for the server. The listener is notified on the client, in the sense = that handleNotification is run on the client JVM. The client becomes the = RMI server and the server the RMI client. Now question is: I want to filter events. I can do this: 1) on client 2) on server Option 1 means also filters are remote objects that are called from the = server. Option 2 means filters are serialized to the server and run there (with = security problems we saw). > Doesn't this problem extend to the MLet service. It is=20 > actually downloading=20 > jars and executing foreign code. My vision is that this=20 > ALWAYS call for a=20 > SecurityManager. Or maybe MLet code should be run in a sandbox "Sandbox" no. Yes, using MLets you can download jars and install nasty MBeans. This = definitely calls for a SecurityManager. There are some trick to be = solved (for example how to update the policy file) though. > Again, to create MBeans remotely you need to have the class=20 > definition on the=20 > server either beforehand (Then it can be considerd trusted)=20 > or later via MLet=20 > in which case there should be a protection. Of course you can=20 > assume that if=20 > somebody can create MLets in the server then the access is=20 > controlled and=20 > trusted Well, in general you cannot. While HTTP adaptor has basic authentication, RMI adaptor has not. So = every one can install it and access the MBeanServer (for now). The point is that with adaptors you need a security manager. However, I will wait to implement this level of security: 1) it will add some complexity to the code (but this does not worry me) 2) it will add *a lot* of complexity for use of adaptors: login, = credentials, permissions. And all dynamic. The JMX spec does not address = security issues, these must be discussed here. For example there should = be a super user that allows to add new management users (that then may = login to a http adaptor). So, many security levels... it must be well = thought. > >I just wanted here to know the opinion on filters, but the security > >issue must be faced. > >Fortunately I know something about it :) > Good ;-) > Perhaps you should take a closer look to the Http/SSL=20 > Adapters, there may be=20 > risks there too. As I told, I would wait to armor our JMX Agent with a tight shield. Simon |
|
From: B. <jer...@xt...> - 2002-01-31 10:20:32
|
Bordet, Simone wrote: [...] >Yes, using MLets you can download jars and install nasty MBeans. This definitely calls for a SecurityManager. There are some trick to be solved (for example how to update the policy file) though. > You can't update a policy file at run-time before JDK 1.4. [...] >2) it will add *a lot* of complexity for use of adaptors: login, credentials, permissions. And all dynamic. The JMX spec does not address security issues, these must be discussed here. For example there should be a super user that allows to add new management users (that then may login to a http adaptor). So, many security levels... it must be well thought. > It depends on the the level of security you want to provide. Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-31 10:25:01
|
Hi, > Regarding your question about=20 > filtering at server or client side, I guess both would work.=20 > The lookup=20 > service in service handles that by saying that this is up to=20 > the client.=20 > So all notifications are sent and filtered on the client side.=20 So, only one should work: client side filtering ;) > The=20 > problem with this scheme is that you should try to send some=20 > few times=20 > the notification (there might be a network congestion for=20 > example) if it=20 > does not work the first time. The call should be threaded too=20 > because we=20 > do not want to block the server while calling the client.=20 No, I do want. At least must be sequential the call for filtering and = notification... Actual implementation is in same thread however: for server there is no = difference between local and remote (I know, I know... :) > Like for a lot of RMI application, I think that OpenJMX=20 > should run under=20 > a security manager (the RMI one would be fine) and a=20 > well-secured policy=20 > file. Yes. > We know from where are coming classes (with the help of codebase=20 > annotations) so why not simply add a sort of firewall? We=20 > could say that=20 > we accept for examples classes coming from location A and B. No, this will be done by the policy file. The real problem is that the = JMX security has totally been forgotten. If a JMXPermission must be = needed to install an MBean, then things would be simpler. Simon |
|
From: B. <jer...@xt...> - 2002-01-31 10:33:11
|
Bordet, Simone wrote: >>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. >> > >No, I do want. At least must be sequential the call for filtering and notification... >Actual implementation is in same thread however: for server there is no difference between local and remote (I know, I know... :) > If you want to garanty order then if you have one remote reference that is "dead" (because of network failure or client crash), you will block the server on this item and the other notifications won't be sent before a while. Is it really important to have a sequential order of notifications? What about adding (like Jini) an eventID and increment this ID each time a notification is sent. That way the client can "re-construct" the order if it matters. Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-31 10:46:18
|
Hi, > >>The=20 > >>problem with this scheme is that you should try to send some=20 > >>few times=20 > >>the notification (there might be a network congestion for=20 > >>example) if it=20 > >>does not work the first time. The call should be threaded too=20 > >>because we=20 > >>do not want to block the server while calling the client.=20 > >> > > > >No, I do want. At least must be sequential the call for=20 > filtering and notification... > >Actual implementation is in same thread however: for server=20 > there is no difference between local and remote (I know, I know... :) > > > If you want to garanty order then if you have one remote=20 > reference that=20 > is "dead" (because of network failure or client crash), you=20 > will block=20 > the server on this item and the other notifications won't be=20 > sent before=20 > a while. Is it really important to have a sequential order of=20 > notifications? What about adding (like Jini) an eventID and increment=20 > this ID each time a notification is sent. That way the client can=20 > "re-construct" the order if it matters. JMX already has event IDs, fortunately. I was talking about filter + notify: these are 2 remote calls, and I = should not do the second if the first filters it out. So I must wait for = the first to complete. So, for each listener I can span a thread, but this thread must call = filter AND notify. One thread per remote call is not good. I don't care notification ordering. Simon |
|
From: B. <jer...@xt...> - 2002-01-31 10:50:46
|
Bordet, Simone wrote: >>If you want to garanty order then if you have one remote >>reference that >>is "dead" (because of network failure or client crash), you >>will block >>the server on this item and the other notifications won't be >>sent before >>a while. Is it really important to have a sequential order of >>notifications? What about adding (like Jini) an eventID and increment >>this ID each time a notification is sent. That way the client can >>"re-construct" the order if it matters. >> > >JMX already has event IDs, fortunately. >I was talking about filter + notify: these are 2 remote calls, and I should not do the second if the first filters it out. So I must wait for the first to complete. > >So, for each listener I can span a thread, but this thread must call filter AND notify. One thread per remote call is not good. > >I don't care notification ordering. > Ok. We were not speaking about the same thing then :-) Perhaps a pool of thread each handling a "filter+notify" operation would be better? Creating threads is really time consuming in Java... Jerome. |
Thanks for helping keep SourceForge clean.
X