appspace pollution :)

[Sean Hinde]

Hi,

> - if there is an inherent flaw in all common web servers it 
> is that they
> serve objects from the filesystem - the same place the important stuff
> (OS, programs, data, etc) is.  The use of chroot should be 
> investigated
> for having OpenFlax serve files.  The practice of serving 
> objects from a
> database (like the wikie) should be investigated.  The webserver code
> would then never access the filesystem directly, but instead rely on a
> database package (such as mnesia).  The drawback would be the 
> extra effort
> required to import the objects you wish to serve, into the database.

This what we do with all our O&M related inets content - it is stored as
binaries (or templates with the static parts as binaries) in mnesia. We
don't find the updating overhead too great given the existence of to_erl -
esp:store("page.html").  or esp:store_all("/Directory/../"). do all the
work.

> - security can always be improved by deleting modules.

Up to a point (os could probably go), but dangerous ones will remain
(file!).

This is a big concern as Erlang creeps ever closer to living on the internet
(Joe punching holes through his home firewall..) Is anyone aware of any
detailed security analysis done on Erlang/OTP? For example there were
vulnerabilities in zlib some time ago (fixed in R9B?).

Also various people have proposed things to lock down erlang distribution:

* Hacking net_kernel to implement a security policy (but it apears that
quite a bit of stuff bypasses net_kernel anyway)

* Using the included ssl for distribution (nice between known hosts but
still allows full access to all services once in)

* Various works at SERC - mainly about non trusted code execution though
some nice stuff about secured gen_servers

* Joe's recent :) statement that "We have done all the work but just haven't
put it in yet"

It would be fantastically powerful to have a locked down distribution
mechanism which looked like normal erlang message passing but only allowed
access to specified services, processes, modules, functions, ports, code
loading etc.

> - {active, true} sockets should probably never be used on a public
> network.  As nicely as they map to the Erlang programming 
> paradigm, they
> present too great a risk of flooding the Erlang runtime with 
> messages. 
> The only times my webserver has actually 'hard' crashed (as opposed to
> processes 'soft' crashing) have been because of message overflow.

Check out {active, once}.

Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.