Very good points, thank you. You articulated my own concerns as I tried to quantify the requirements, and what the risks are.
The central need here is the ability to compute formulas that are not entirely under your own control. In my case, I want to provide the ability to evaluate APL expressions on the #jsoftware IRC channel. They already have a bot that does J, so APL is clearly needed. There are of course other use cases, and as you pointed out a single option may not be enough (or be too much). I'm starting to think about a more granular mechanism. Some way of evaluating just a single expression using very strict protections, but letting the rest be unconstrained. Controlled using a quad variable perhaps? (the variable could contain a list of the operations that should be allowed or denied when evaluating a given string). Regards, Elias On 29 Mar 2017 23:40, "Juergen Sauermann" <juergen.sauerm...@t-online.de> wrote: > Hi Elias, > > I understand and to some extent support the desire to make the safe mode > more safe. However, we should not go too far with it because > that has the risk of making --safe so restrictive that useful operations > are no linger possible. > > For example disabling SQL operations completely would make it impossible > to display data from an SQL file in a web page. > I would rather argue that in this example, setting the file permissions of > the SQL files would be more appropriate than disabling SQL > entirely. I also tend to believe that it is simply impossible to implement > the security of a machine as a single command-line option > of one program. > > And e.g. preventing *)COPY* would render many existing workspaces > useless. For example, my own HTML pages do *)COPY HTML* > before anything else. Preventing *⎕FIO* would also disable socket() > operations which are quite useful if you want to do a web server > directly in apl. > > So lets discuss what a reasonable list would look like, and then (based on > the length of the list) how to implement the restrictions > (via ./configure, or in preferences files, or as command line option(s)). > > Best Regads, > /// Jürgen > > > On 03/29/2017 06:21 AM, Elias Mårtenson wrote: > > I'm implementing an IRC bot that can run arbitrary APL expressions. Since > this bot can run code submitted by anyone, I need to ensure that the code > can't affect the system where the APL expressions are executed. > > This is the purpose of the --safe flag, but I have noted that several > destructive operations are still permitted when using this flag. > > In particular: > > > - SQL operations > - FILE_IO > - )OUT > - )DUMP, )DUMPV, )DUMP-HTML > - )COPY, )LOAD, etc… > - )HOST > > There is probably more, but preventing these would be a good start. > > Regards, > Elias > > >
