I think it would be a good idea in another context. I think that forbidding IO completely is better aligned with the intentional use of the TIC-80 which is meant to be a fantasy console. The scheme code runs directly on the fictionnal hardware (a bit like your assembly would run from a NES cartridge). There shouldn't be any persistent file systems / storage accessible to users using that premise.
On Fri, Feb 3, 2023 at 1:23 PM Massimiliano Gubinelli <[email protected]> wrote: > What about implementing a fake filesystem instead of allowing s7 to access > the real one? In this way it will be effectively sandboxed. This is the > approach used by emscripten to have ports work in webasm. > > Max > > > On 3 Feb 2023, at 13:43, David St-Hilaire <[email protected]> > wrote: > > I think it's mostly writing to files that is dangerous but disabling > reading would be important too, if not only for forbidding "breaking" the > fantasy console barriers. I looked at doing some changes but I was really > not sure how to do it properly. If you would be generous enough to do > the needed changes, it would be really amazing! > > Thank you so much for your help! > > On Fri, Feb 3, 2023 at 8:32 AM <[email protected]> wrote: > >> Do you need to disallow reading a file? If it's just >> creating or altering a file that needs to be blocked, >> you could redirect fopen and fwrite (in s7.c) to >> functions that raise an error. I don't think s7 uses >> creat, open (except with O_RDONLY), or write. Also >> build it with WITH_C_LOADER=0 (to disallow dynamic >> loading of C object code), and maybe WITH_SYSTEM_EXTRAS=0. >> Hmmm... as I type this, this seems interesting -- >> maybe I'll tackle it later today. It might be >> equally easy to disallow reading a file -- fread etc. >> Oh, and for fopen, check the mode doesn't have "w" or "x" >> or whatever else might change a file. I'm probably >> forgetting something obvious. >> >> (There's also the sandbox procedure in stuff.scm, but >> it's been years since I looked at it). >> >> >> > > -- > David > _______________________________________________ > Cmdist mailing list > [email protected] > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > > > -- David
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
