On 20/02/2014, at 8:21 PM, srean wrote:
>
> Ah I see, this is a lot better. The last time I tried the installation was
> starting the webservice on its own. Or am I/was hallucinating ?
Look in the Makefile. Normal make install doesn't start anything.
I have a
make install-felix-lang.org
that I use installing Felix on felix-lang.org, which stops the webserver during
the install and restarts it afterwards. This is to avoid writing on top of
a currently executing binary which works fine on BSD and OSX but fail
on Linux.
The actual script I use on Linux is in misc/felixweb.conf, it allows
starting and stopping the webserver as a service. There's also
misc/felixweb.plist which is for OSX, does the same thing.
Neither of these scripts work unless you install them manually.
It's a good idea to do this IMHO because browsing Felix doc on
the local machine requires a webserver and without it running
you'll probably not bother to start it.
>
> > Read permissions of big bad world should be < account holder's read
> > permissions
>
> Thats a logical absurdity.
Can I sell you a perpetual motion machine?
> Not sure what the right thing should be though. Its a lot better now that the
> server needs to be started explicitly, but given that all the prominent ones
> come with some default sensible security settings, I am pretty sure many
> users would assume the same.
You're really missing the point. A webserver cannot provide security. ***
The only thing I can change sensibly is the default port. Probably the sensible
thing to do is not have one. Perhaps you have a suggestion as to the default?
I just picked 1234 at "random" for no reason :)
A webserver can BE secure. This means not writing it in that idiot language C
which allows buffer overruns, null pointer exploits, etc. And it means not
doing rubbish like trying to restrict access to things because that's rubbish.
This simply opens the system up to exploits.
Look at crap like Ruby on Rails which had exactly that problem.
The right way to provide security on a Unix system is to use the
tools DESIGNED to provide security: ipchains/tables or other
firewalls, account privileges, on more advanced systems limits
on resource usage.
The only "security" issues a webserver needs to deal with is sockets
and http/https requests, because that IS the domain in which it is
operating.
And that one is a bit of problem at the moment, but we know about it.
Demux/faio doesn't support timeouts on I/O requests.
The other issue is that the design of sockets is crap. The API is bad.
There's no sane way to close an asynchronous socket.
That's not my fault. The webserver does what it can.
if you want a summary of that one: there are two kinds of DoS attacks:
a connection which sends slowly and a connection which sends too much.
The first one can be handled with a timeout, i.e. a minimal rate monitor.
The second one can be handled by a size monitor.
Both these monitors are essential to ensure every open socket is
being utilised at a reasonable rate for a reasonable period.
Both these thing could be done (even if they aren't now) for sockets
during intercourse with a client. Unfortunately there's no way to
do it when shutting down the connection. Not that I know of anyhow.
Sockets are a really stupid idea in the first place. They shouldn't
be streams, and they shouldn't be bidirectional. Blame BSD on that one :)
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
