2

I have a program that, for data security reasons, should never persist anything to local storage if deployed in the cloud. Instead, any input / output needs to be written to the connected (encrypted) storage instead.

To allow deployment locally as well as to multiple clouds, I am using the very useful fsspec. However, other developers are working on the project as well, and I need a way to make sure that they aren't accidentally using local File I/O methods - which may pass unit tests, but fail when deployed to the cloud.

For this, my idea is to basically mock/replace any I/O methods in pytest with ones that don't work and make the test fail. However, this is probably not straightforward to implement. I am wondering whether anyone else has had this problem as well, and maybe best practices / a library exists for this already?

During my research, I found pyfakefs, which looks like it is very close what I am trying to do - except I don't want to simulate another file system, I want there to be no local file system at all.

Any input appreciated.

Thomas
  • 4,696
  • 5
  • 36
  • 71

1 Answers1

1

You can not use any pytest addons to make it secure. There will always be ways to overcome it. Even if you patch everything in the standard python library, the code always can use third-party C libraries which can't be patched from the Python side.

Even if you, by some way, restrict every way the python process can write the file, it will still be able to call the OS or other process to write something.

The only ways are to run only the trusted code or to use some sandbox to run the process.

In Unix-like operating systems, the workable solution may be to create a chroot and run the program inside it.

If you're ok with just preventing opening files using open function, you can patch this function in builtins module.

_original_open = builtins.open

class FileSystemUsageError(Exception):
    pass

def patched_open(*args, **kwargs):
    raise FileSystemUsageError()

@pytest.fixture
def disable_fs():
    builtins.open = patched_open
    yield
    builtins.open = _original_open

I've done this example of code on the basis of the pytest plugin which is written by the company in which I work now to prevent using network in pytests. You can see a full example here: https://github.com/best-doctor/pytest_network/blob/4e98d816fb93bcbdac4593710ff9b2d38d16134d/pytest_network.py

Pavel Shishmarev
  • 1,335
  • 9
  • 24
  • I am aware that there will be ways around it, however, I am not assuming malevolence on the side of the developer - this question is more about catching accidental usage of any file I/O that might happen, e.g. someone using `pandas.read_csv()` with a local path instead of `with my_fs.open(cloud_path) as f: pd.read_csv(f)` – Thomas Aug 09 '22 at 08:23
  • I've updated the answer with just patching `open` – Pavel Shishmarev Aug 09 '22 at 08:31
  • There is some probability that pd.read_csv will still work, if it is using C-code to read files, then you will just need to patch the pd.read_csv as well – Pavel Shishmarev Aug 09 '22 at 08:33
  • 1
    Hi Pavel, thanks for the effort, but a code solution is not what I am looking for, since it will always be incomplete - for example, open might be patched now, but there is still os.mkdir, os.listdir, pathlib.Path.isdir, write, and numerous other i/o operations. I want to see whether anybody has already tackled this problem before implementing all of that from scratch... – Thomas Aug 09 '22 at 11:09