module blocklist/passlist for config files

[ntessore]

We should implement a blocklist mechanism for potentially harmful modules, so that one cannot distribute a config file:

bye: !os.system [ 'rm -rf important_file' ]

We could block os and sys by default. But since there are arbitrarily many potentially hazardous operations, we could also implement a passlist for modules that the user can add to, if we ever implement some sort of configuration system.

[JonathanDHarris]

@ntessore I'm wondering what sort of use cases you're guarding against here. If the user is on their own machine then I guess it's up to them to make sure their config files are safe.

Are you thinking about, e.g., running on a university machine that students can submit code to? Maybe the best approach is to make clear in the installation guide that skypy should have its own user when it runs so it can't get the permissions to cause damage.

Or something else that I've not thought of?

[ntessore]

If someone sends me a YAML file, I am much less aware of the fact that it can erase my entire file system than when someone sends me a Python code. I think we should have at least a best-effort safeguard in place to prevent bad things from happening.

[JonathanDHarris]

How would you feel about the pipeline displaying a warning about untrusted config files when it runs?

[rrjbca]

My first instinct is a passlist for modules imported by Pipeline that defaults to astropy, numpy, scipy and skypy, and a command line flag / Pipeline kwarg to add additional modules at runtime. Then we can try it out and see if it's overly restrictive.