Just a thought... What if --safe took an argument, like "--save 1", "--safe 2", etc.
On Wed, Mar 29, 2017 at 10:52 AM, Elias Mårtenson <loke...@gmail.com> wrote: > 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 >> >> >>
