restricted execution

Lawrie Brown Lawrie.Brown@REDACTED
Wed Jun 11 02:06:48 CEST 2003


On Tue, Jun 10, 2003 at 07:54:31PM -0400, erlang@REDACTED wrote:
> > The essence of the answer is to ensure that the "untrusted" erlang node is
> > forced to use a (more) trusted node to mediate all external communications
> > to ensure it conforms to your policy. As it stands I don't believe the
...
> Actually, environment constraints are feasible in my envisioned application.
> I can almost certainly use a read-only filesystem, and only have network
> connectivity to other erlang-using machines, hence no generalised internet
> access (unless mediated by a trusted erlang node).  The hard part is 
> forcing other erlang nodes into not honouring spawn commands, but still
> accepting ordinary messages.

This is getting into an area I've not investigated in detail, but I'd suggest
firstly looking at the node type - there is a "hidden" node type usually
used for C-nodes that does not advertise itself, whether a normal OTP node
can be coerced into being such I'm not sure.

The other point is indeed to play with the list of applications launched
at startup, especially the ones which manage the list of known nodes, 
which could then be limited.

Let me know how you go.

Cheers
Lawrie

------------------------------------ <*> ------------------------------------
Post: Dr Lawrie Brown, Computer Science, UNSW@REDACTED, Canberra 2600 Australia
Phone: 02 6268 8816    Fax: 02 6268 8581    Web: http://www.adfa.edu.au/~lpb/ 



More information about the erlang-questions mailing list