Why is file reading enabled by default? about asteval HOT 3 CLOSED

@jmdejong Well, open() might be useful. It is a security risk only to the extent that user is permitted by the file system to read/write, right?

That said, I suppose it could be removed...

from asteval.

Most use cases for asteval that I can think of would have files with private data on the same filesystem.
A likely usecase for asteval would be a game that allows scripting. In this example, the same filesystem (with the same user permissions) might contain a file with the passwords of the players.

A second problem is that this can easily exceed the max_time.
Reading from /dev/urandom will never finish, and because it doesn't pass through run the max_time check will not be able to stop it.

from asteval.

@jmdejong

Most use cases for asteval that I can think of would have files with private data on the same filesystem.

Wouldn't that always be the case?

A likely usecase for asteval would be a game that allows scripting. In this example, the same filesystem (with the same user permissions) might contain a file with the passwords of the players.

Well, asteval is designed to allow an "outer, wrapping" program to do calculations using strings input by outside users. Those strings have to be viewed by the outer program as untrusted or perhaps "trusted" in the sense that the outer program is willing to take that input passed in by users and run it through astevals interpreter.

The outer program might want to allow users to open files. It might also want to restrict which files it can open. It might want to run under some special user account (say, "apache" or "nobody") that cannot access some files based on file system permissions. Those are all possible.

open is just a symbol in astevals symbol table that points to Python's open function. It can be replaced with a different function or removed from that symbol table. FWIW, if using numpy, there are also functions load and loadtxt that can also access the disk.

A second problem is that this can easily exceed the max_time.
Reading from /dev/urandom will never finish, and because it doesn't pass through run the max_time check will not be able to stop it.

max_time is deprecated. It is actually not possible for a single Python process to have a runtime restriction. Once Python enters C code (as with any i/o or even a potentially long running calculation like 777), the Python interpreter is stuck and there is no way out from that process.

To restrict resource hogging, you would have to use a supervisory process to check (for example) that the asteval-running outer process had not returned (for example, writing a heartbeat message), and act on that. There really isn't anything we can add to asteval itself to aid that. That is, a long running asteval calculation might be in some asteval for-loop and returning to asteval code (in which case a max_time mechanism might work), but it might be stuck in C code (like pow() or i/o).

from asteval.