ocamlnet-devel

[Ocamlnet-devel] Two issues with Netplex

[Thomas C. <cal...@gm...>]

Hi there,

I am having two issues with netplex at the moment.

The first one is related to rpc-ssl support. The netplex service is
configured with SSL enabled (TLSv1) and if you are connecting with a client
that forces newer TLS versions (openssl s_client -connect host:port
-tls1_1), an Ssl exception is raised.
However, the container process still continues to run but is not able to
process any data, netplex then spawn a new child process to handle
subsequent connections.
>From the client side, the socket is closed and we end up not knowing in
which state the "zombie" container is.
We looked for a proper way to fix this in our code, but the exception is
caught from within rpc_netplex.ml (line 183), is there a proper way to
handle this case from our code or is it only a fix you can provide ?

The second issue is related the function "Netplex_cenv.system_shutdown()".
This function can be used to completely shutdown the service, I would like
to know if it is possible to restrict this function to be only callable
from within the controller instance ? This way a container process could
not call this function and stop the service and all the other containers
from running.

Thanks.

Thomas C.

Re: [Ocamlnet-devel] Two issues with Netplex

[Gerd S. <in...@ge...>]

Am Donnerstag, den 07.11.2013, 19:34 +0100 schrieb Thomas Calderon:
> Hi there,
> 
> 
> I am having two issues with netplex at the moment.
> 
> 
> The first one is related to rpc-ssl support. The netplex service is
> configured with SSL enabled (TLSv1) and if you are connecting with a
> client that forces newer TLS versions (openssl s_client -connect
> host:port -tls1_1), an Ssl exception is raised.

Well, the ocaml-ssl bindings only offer TLS-1.0, even if openssl
supports more. That's basically a problem of the bindings. (Fyi, I'm
currently implementing complete bindings for GnuTLS to overcome all
limitations with ocaml-ssl.)

> However, the container process still continues to run but is not able
> to process any data, netplex then spawn a new child process to handle
> subsequent connections. 
> From the client side, the socket is closed and we end up not knowing
> in which state the "zombie" container is.
> We looked for a proper way to fix this in our code, but the exception
> is caught from within rpc_netplex.ml (line 183), is there a proper way
> to handle this case from our code or is it only a fix you can
> provide ?

You could close fd, and then call when_done() from the is_error
callback. This is how it is indicated that the task is done.

Probably this is really the best thing you can do here. When I
programmed this I could probably not imagine what kind of things can go
wrong at this spot, and hence opted to do nothing.

> The second issue is related the function
> "Netplex_cenv.system_shutdown()". This function can be used to
> completely shutdown the service, I would like to know if it is
> possible to restrict this function to be only callable from within the
> controller instance ? This way a container process could not call this
> function and stop the service and all the other containers from
> running.

Without modifying the sources, there is probably no way to get this
effect.

What's actually happening is that the controller accepts requests on the
admin socket (which is a Unix domain socket visible in the filesystem),
and if the container wants to do a system shutdown, is just connects to
this socket, and invokes the right RPC. I don't see how you could
prevent the container from doing so even if the connect code were
removed from the netplex sources. Maybe the only way is to set a
password on this service, and not telling the container the password.

Out of curiosity, what's your concern with system shutdowns? 

Gerd

> 
> Thanks.
> 
> 
> Thomas C.
> 
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________ Ocamlnet-devel mailing list Oca...@li... https://lists.sourceforge.net/lists/listinfo/ocamlnet-devel

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    ge...@ge...
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

Re: [Ocamlnet-devel] Two issues with Netplex

[Thomas C. <cal...@gm...>]

Hi Gerd,




On Sun, Nov 10, 2013 at 1:24 PM, Gerd Stolpmann <in...@ge...>wrote:

> Am Donnerstag, den 07.11.2013, 19:34 +0100 schrieb Thomas Calderon:
> > Hi there,
> >
> >
> > I am having two issues with netplex at the moment.
> >
> >
> > The first one is related to rpc-ssl support. The netplex service is
> > configured with SSL enabled (TLSv1) and if you are connecting with a
> > client that forces newer TLS versions (openssl s_client -connect
> > host:port -tls1_1), an Ssl exception is raised.
>
> Well, the ocaml-ssl bindings only offer TLS-1.0, even if openssl
> supports more. That's basically a problem of the bindings. (Fyi, I'm
> currently implementing complete bindings for GnuTLS to overcome all
> limitations with ocaml-ssl.)
>

OK that's what I thought as well, I added the missing symbols to
ocaml-ssland some other missing features (DH/
ECDH). This is immediately available from the git version of the code, but
having a GnuTLS alternative is also good news.


>
> > However, the container process still continues to run but is not able
> > to process any data, netplex then spawn a new child process to handle
> > subsequent connections.
> > From the client side, the socket is closed and we end up not knowing
> > in which state the "zombie" container is.
> > We looked for a proper way to fix this in our code, but the exception
> > is caught from within rpc_netplex.ml (line 183), is there a proper way
> > to handle this case from our code or is it only a fix you can
> > provide ?
>
> You could close fd, and then call when_done() from the is_error
> callback. This is how it is indicated that the task is done.
>

Alright I'll look into this to fix the issue with the current ocaml-sslbindings.


>
> Probably this is really the best thing you can do here. When I
> programmed this I could probably not imagine what kind of things can go
> wrong at this spot, and hence opted to do nothing.
>
> > The second issue is related the function
> > "Netplex_cenv.system_shutdown()". This function can be used to
> > completely shutdown the service, I would like to know if it is
> > possible to restrict this function to be only callable from within the
> > controller instance ? This way a container process could not call this
> > function and stop the service and all the other containers from
> > running.
>
> Without modifying the sources, there is probably no way to get this
> effect.
>
> What's actually happening is that the controller accepts requests on the
> admin socket (which is a Unix domain socket visible in the filesystem),
> and if the container wants to do a system shutdown, is just connects to
> this socket, and invokes the right RPC. I don't see how you could
> prevent the container from doing so even if the connect code were
> removed from the netplex sources. Maybe the only way is to set a
> password on this service, and not telling the container the password.
>

OK thanks for your input on that.


>
> Out of curiosity, what's your concern with system shutdowns?
>

Netplex controller can be seen as task schedulers spawning child processes
to handle requests.
Now let's suppose the service your are offering becomes essential on your
system, then availability becomes something you really care about. For
example if one of the container's flow of execution is compromised, you can
can live with that as long as it cannot hurt your availability or use
privileged APIs.

I'll have a look at the admin socket and check if nothing more can be done
here.

Thanks for your answers.

Thomas C.


>
> Gerd
>
> >
> > Thanks.
> >
> >
> > Thomas C.
> >
> >
> >
> ------------------------------------------------------------------------------
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models.
> Explore
> > techniques for threading, error checking, porting, and tuning. Get the
> most
> > from the latest Intel processors and coprocessors. See abstracts and
> register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> > _______________________________________________ Ocamlnet-devel mailing
> list Oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocamlnet-devel
>
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany    ge...@ge...
> My OCaml site:          http://www.camlcity.org
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> ------------------------------------------------------------
>
>

Re: [Ocamlnet-devel] Two issues with Netplex

[Thomas C. <cal...@gm...>]

Hi Gerd,

I have successfully tested the fix you mentioned in your reply.
You'll find attached a patch to address the issue (for ocamlnet-3.6.6) of
child containers becoming zombies when the socket connection fails
unexpectedly.

It would be great if this modification could make it upstream.

Regarding the system_shutdown() issue we discussed I have not made any
progresses, it would be great if we could filter the RPC calls available to
child
containers given a policy defined by the controller process.

Regards.

Thomas C.


On Mon, Nov 11, 2013 at 9:15 AM, Thomas Calderon
<cal...@gm...>wrote:

> Hi Gerd,
>
>
>
>
> On Sun, Nov 10, 2013 at 1:24 PM, Gerd Stolpmann <in...@ge...>wrote:
>
>> Am Donnerstag, den 07.11.2013, 19:34 +0100 schrieb Thomas Calderon:
>> > Hi there,
>> >
>> >
>> > I am having two issues with netplex at the moment.
>> >
>> >
>> > The first one is related to rpc-ssl support. The netplex service is
>> > configured with SSL enabled (TLSv1) and if you are connecting with a
>> > client that forces newer TLS versions (openssl s_client -connect
>> > host:port -tls1_1), an Ssl exception is raised.
>>
>> Well, the ocaml-ssl bindings only offer TLS-1.0, even if openssl
>> supports more. That's basically a problem of the bindings. (Fyi, I'm
>> currently implementing complete bindings for GnuTLS to overcome all
>> limitations with ocaml-ssl.)
>>
>
> OK that's what I thought as well, I added the missing symbols to ocaml-ssland some other missing features (DH/
> ECDH). This is immediately available from the git version of the code,
> but having a GnuTLS alternative is also good news.
>
>
>>
>> > However, the container process still continues to run but is not able
>> > to process any data, netplex then spawn a new child process to handle
>> > subsequent connections.
>> > From the client side, the socket is closed and we end up not knowing
>> > in which state the "zombie" container is.
>> > We looked for a proper way to fix this in our code, but the exception
>> > is caught from within rpc_netplex.ml (line 183), is there a proper way
>> > to handle this case from our code or is it only a fix you can
>> > provide ?
>>
>> You could close fd, and then call when_done() from the is_error
>> callback. This is how it is indicated that the task is done.
>>
>
> Alright I'll look into this to fix the issue with the current ocaml-sslbindings.
>
>
>>
>> Probably this is really the best thing you can do here. When I
>> programmed this I could probably not imagine what kind of things can go
>> wrong at this spot, and hence opted to do nothing.
>>
>> > The second issue is related the function
>> > "Netplex_cenv.system_shutdown()". This function can be used to
>> > completely shutdown the service, I would like to know if it is
>> > possible to restrict this function to be only callable from within the
>> > controller instance ? This way a container process could not call this
>> > function and stop the service and all the other containers from
>> > running.
>>
>> Without modifying the sources, there is probably no way to get this
>> effect.
>>
>> What's actually happening is that the controller accepts requests on the
>> admin socket (which is a Unix domain socket visible in the filesystem),
>> and if the container wants to do a system shutdown, is just connects to
>> this socket, and invokes the right RPC. I don't see how you could
>> prevent the container from doing so even if the connect code were
>> removed from the netplex sources. Maybe the only way is to set a
>> password on this service, and not telling the container the password.
>>
>
> OK thanks for your input on that.
>
>
>>
>> Out of curiosity, what's your concern with system shutdowns?
>>
>
> Netplex controller can be seen as task schedulers spawning child
> processes to handle requests.
> Now let's suppose the service your are offering becomes essential on your
> system, then availability becomes something you really care about. For
> example if one of the container's flow of execution is compromised, you
> can can live with that as long as it cannot hurt your availability or use
> privileged APIs.
>
> I'll have a look at the admin socket and check if nothing more can be done
> here.
>
> Thanks for your answers.
>
> Thomas C.
>
>
>>
>> Gerd
>>
>> >
>> > Thanks.
>> >
>> >
>> > Thomas C.
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > November Webinars for C, C++, Fortran Developers
>> > Accelerate application performance with scalable programming models.
>> Explore
>> > techniques for threading, error checking, porting, and tuning. Get the
>> most
>> > from the latest Intel processors and coprocessors. See abstracts and
>> register
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> > _______________________________________________ Ocamlnet-devel mailing
>> list Oca...@li...
>> https://lists.sourceforge.net/lists/listinfo/ocamlnet-devel
>>
>> --
>> ------------------------------------------------------------
>> Gerd Stolpmann, Darmstadt, Germany    ge...@ge...
>> My OCaml site:          http://www.camlcity.org
>> Contact details:        http://www.camlcity.org/contact.html
>> Company homepage:       http://www.gerd-stolpmann.de
>> ------------------------------------------------------------
>>
>>
>