Re: [PATCH] bash: add socket server support

[Mike Frysinger]

On Thursday 14 November 2013 11:32:18 Cedric Blancher wrote:
> On 13 November 2013 15:46, Joel Martin wrote:
> > On Wed, Nov 13, 2013 at 6:39 AM, Irek Szczesniak wrote:
> >> The other problems I see is:
> >> How can the script get access to the data returned by accept()? Unlike
> >> ksh93 bash4 has no compound variables yet.
> >> How can the accept() socket be passed to a child process so that
> >> request processing can be passed to a fork()ed child process?
> > 
> > The accept socket is not exposed to the script by this change.
> 
> Why?
> 
> What happens if someone wishes to set more flags on that socket?

does bash even support setting flags on sockets today ?  if not, then demanding 
more than the status quo here is a bit unreasonable.

> Or
> wishes to have the per-accept() data, like the requester address? Not
> all protocols (say, NFS or non-krb5 rsh protocols) embed the request
> address in the request itself, and if you look at the Apache archives
> it can even be considered an attack of the address from accept() and
> in the request do not match (requester spoofing attack).
> 
> So far I can see the server socket you implemented is only barely
> enough to do a HTTP server, and not even an good one.

it's fsckin bash for fsck sake.  it's never going to be able to be a "good" 
server.  it's meant for quick hacks.  if you have an important service 
utilizing this stuff, then your infrastructure deserves to burn to the ground 
when it fails :P.

> Maybe a better way would be to implement something which creates a
> server socket for accept, and then have a poll builtin (coincidentally
> ksh93v- has a very nice poll(1) implementation) which can be used to
> wait both on the accept socket and the sockets returned by accept. If
> the accept sockets returns an event you could use something like
> /dev/tcpserver/nextaccept to open to obtain the next socket returned
> by accept(), and store the accept() data in an env variable.

adding other features like this doesn't sound like a bad idea at all, but it 
also doesn't sound like it should preclude a simple & useful extension to 
existing bash code.
-mike

signature.asc
Description: This is a digitally signed message part.