Preference for Performance

I am still in catching-up mode, trawling through the literature, where inevitably you will find research work which is not representative of the state of the art. So the reader will forgive me if some of the publications I cover are obsolete or otherwise misleading as of the status of Erlang Security. Sadly my limited knowledge does not allow me to be too selective!

In any case, it is clear that at present only a handful of papers and other publications address Security for/in Erlang environments.  Many do not. Just as a reference, you can check the paper titled “Mnesia – A Distributed Robust DBMS for Telecommunications Applications” by Hakan Mattsson, Hans Nilsson and Claes Wikström (source: http://erlang.se/publications/mnesia_overview.pdf ). This is an informative document describing the functionality of the Mnesia database which is part of the Erlang-OTP platform. If you are studying Erlang you should read this paper.

The document succeeds in presenting Mnesia and Erlang while highlighting powerful capabilities related to real-time key/value lookup, data complexity, distributed data management and high fault tolerance. The overview of the Mnesia data model is also quite useful: “The data model of Mnesia is of a hybrid type: data is organized as tables of records similar to relations, but the attributes of the records (including the key) can hold arbitrary complex compound data structures such as trees, functions, closures, code, etc. As such, Mnesia could be characterized as a so called object-relational DBMS.”

How do you execute a transaction in Mnesia? The authors say: “In order to have Mnesia execute a transaction, the programmer must construct a functional object and then present the Mnesia system with their functional object…” – and present good examples of this type of operations, highlighting the functional nature of the Erlang language.

In the same manner, “Queries in Mnesia are expressed with a list comprehension syntax” or with “rules” (see page 4 of the paper).  The authors detail that a rule “acts as a virtual table and application programs can access the virtual table”.

Even more interestingly, we learn that “Tables can be replicated to several sites (or nodes). The network of nodes can be a heterogeneous network. Replication is the mechanism whereby we can construct fault tolerant systems,” all of which constitute excellent qualities.

Nevertheless, in the same paragraph we see what is perhaps the greatest limitation of this paper: the absence of Security focus. The authors write: “Access to a table is location transparent, that is programs do not have to have explicit knowledge of the location of the data.” But, what then is the context of the query? If data is passed from node to node and queries can be effected indistinctly on every node, what controls the authorisation level of the caller?

The authors list the “properties” attached to a table as follows:

-type, i.e. set or bag semantics

-num_copies, the list of nodes where replicas exist

-disc_only_copies, the list of nodes where replicas of the table are held on disc only

-index, a list specifying which attributes shall be indexed

-snmp, indicates whether the table can be manipulated through SNMP

A quite detailed discussion of lookup operations, data format and fault tolerance. A description of ACID (atomicity, consistency, isolation and durability) transactions follows, and we learn that (apparently according to practice) most Mnesia transactions occur in RAM only and hence the Durability aspect is not fulfilled. The Mnesia database seems them strongly geared towards atomic real-time or near-real-time transactions.

As before, there is no Security focus, although one could argue that pure data handling primitives already constitute a good starting point. Security though has as one of its determinants that it has to be conscious, i.e. a series of conscious choices, to be meaningful. We cannot assess a system as secure just because it exhibits the right data handling routines. I am therefore at this point concerned when thinking that the Mnesia database completely depends for its security (session management and authorisation levels) on the client/server mechanisms, that is on the application level.

The authors describe for example on page 8 “the ability to bypass the transaction manager,” which refers to the possibility of programmatically executing data reads without calling the Mnesia transaction engine which offers concurrency controls, but we learn that the programmer can “read, write and search Mnesia tables without protecting the operation inside a transaction.”  This is curiously lauded as follows: “These dirty operations are true real-time DBMS operations: they take the same predictable amount of time regardless of the size of the database.”  To which we would ad that we can find here a unilateral engineering approach which needs to be addressed in a real application development context.

I still have to understand how data storage is implemented. From the paper we learn that, “persistent storage is implemented on top of the underlying operating system file system”  – which builds on the perception that there is a complete dependency of Mnesia on its environment for Security capabilities. This seems to come from the intentions of the designers: “Since Mnesia is primarily intended to work as primary memory DBMS, we feel that the portability aspect is the more important” – according to the authors.