mueval changes currentDir without resetting

[jwaldmann]

When reading from a file, mueval changes the current directory and never resets it?

https://github.com/gwern/mueval/blob/master/Mueval/Interpreter.hs#L109

I think this should be documented - or changed. I am using this work-around:

https://gitlab.imn.htwk-leipzig.de/autotool/all0/blob/master/collection/src/Haskell/Blueprint/Central.hs#L120

[jwaldmann]

But the work-around cannot be applied in a concurrent setting (several muevals forkIO'ed) since the "current directory" is a property of the OS process, of which there's only one?

[gwern]

You shouldn't be depending on mueval to be doing anything at the OS level. A mueval invocation is toxic waste to be thrown away as quickly as possible. (Ideally, one would run it in a new VM entirely, but I never got as far as considering how to make that workable.) It could be frozen, it could be in the middle of being corrupted, it could have been crippled by a partial attack... If you are depending mueval to read, parse, & execute untrusted evil Internet-controlled inputs and are relying on it to do anything at all after having done that such as changing environment state, that is wrong and a potential source of vulnerabilities. I don't know about concurrent settings, although forking new processes instead of green threads seems like the obvious thing to do?

[jwaldmann]

Yes I am taking that route now (evaluation in a separate process inside chroot).

Your warnings are entierly understood, although it's mitigated somewhat since I am running code only after the AST matches a given pattern (it's for "fill the holes" programming exercises). The pattern also prescribes imports and pragmas, so students cannot use unsafePerformIO. There's still the risk of DOS via non-termination.

For reference, this "concurrent setting" issue only surfaced because we were switching our backend service from CGI (one process per request) to servant (just one OS process).