Octave restricted mode?

[John W. Eaton]

On 15-Mar-2010, Jaroslav Hajek wrote:

| for use of Octave in web applications (which I'm myself interested
| in), I started to think about allowing Octave to run in a "secure"
| mode.
| For instance, it could include the following restrictions:
| 
| 1. spawning external processes (system, popen, fork, exec etc) is not allowed
| 2. cd is not allowed
| 3. mkfifo, symlink, etc are not allowed
| 4. addpath etc. are not allowed
| 5. only files in current directory can be fopen()-ed, stat()-ed etc.
| 6. likewise for other compiled functions where this is possibly needed.
| 
| I know this won't make Octave hacker-proof, because exploitable bugs
| (like buffer overruns) are to be expected in Octave, but at least it
| should make it significantly harder to hack a web application
| providing access to Octave terminal.
| 
| thoughts?

Would you disallow all uses of these functions, or just direct uses
from teh command line, or functions defined by a user in this
restricted environment (i.e., the functions the user uploads to the
server that is running the restricted-mode Octave)?  If you disallow
all uses, then you will break a lot of things.  For example, the help
system.

I think it makes more sense to leave Octave alone and instead create a
server environment (chroot jail or similar) that makes it impossible
for a user to do any damage to the server or anyone elses environment.

jwe