有没有一种方法可以用pytest进行沙盒测试，尤其是文件系统访问？

Question

我对在某种沙箱中使用pytest执行潜在的不可信测试感兴趣，比如docker，类似于continuousintegrationservices所做的工作。在

我知道，要正确地对python进程进行沙箱化，您需要操作系统级的隔离，就像在一次性chroot/容器中运行测试一样，但在我的用例中，我不需要防止故意恶意代码，只需要防止将“随机”函数与参数配对的危险行为。因此，不那么严格的沙盒仍然可以接受。但是我没有找到任何插件来支持任何形式的沙盒。在

在pytest中执行沙盒测试的最佳方法是什么？在

更新：这个问题不是关于python sandboxing in general的，因为测试的代码是由pytest运行的，我不能改变它的执行方式来使用exec或{}或其他任何东西。不幸的是，使用pypysandbox并不是一个选项，因为根据PyPy feature page，它是“仅一个原型”。在

更新2：用户级隔离的pytest dev邮件列表suggests using a dedicated testuser via pytest-xdist上的Hoger Krekel：

py.test --tx ssh=OTHERUSER@localhost --dist=each

其中made me realise对于我的类CI用例：

having a "disposable" environment is as important as having a isolated one, so that every test or every session runs from the same initial state and it is not influenced by what older sessions might have left on folders writable by the testuser (/home/testuser, /tmp, /var/tmp, etc).

因此testuser+xdist接近于解决方案，但还不完全存在。在

为了上下文，我需要隔离来运行pytest-nodev。在

Answer 1

经过相当多的研究之后，我没有找到任何现成的方法让pytest在操作系统级别的隔离环境中运行项目测试。很多方法都是可行的，有优点也有缺点，但大多数方法都有我觉得舒服的活动部件。在

我设计的绝对最小（但固执己见）方法如下：

• 使用以下内容构建python docker映像：
  • 专用非根用户：pytest
  • 来自requirements.txt的所有项目依赖项
  • 项目以开发模式安装
• 跑py.测试在一个容器中，该容器将项目文件夹作为pytest用户的主目录装载到主机上

要实现该方法，请将以下Dockerfile添加到要测试的项目的顶层文件夹中requirements.txt和setup.py文件旁边：

FROM python:3

# setup pytest user
RUN adduser  disabled-password  gecos ""  uid 7357 pytest
COPY ./ /home/pytest
WORKDIR /home/pytest

# setup the python and pytest environments
RUN pip install  upgrade pip setuptools pytest
RUN pip install  upgrade -r requirements.txt
RUN python setup.py develop

# setup entry point
USER pytest
ENTRYPOINT ["py.test"]

使用以下方法构建映像：

^{pr2}$

跑py.测试在容器内部，将项目文件夹作为卷装载到/home/pytest上：

docker run  rm -it -v `pwd`:/home/pytest pytest [USUAL_PYTEST_OPTIONS]

请注意，-v将卷挂载为uid 1000，这样pytest用户将无法写入uid为7357的主机文件。在

现在您应该能够使用操作系统级别的隔离来开发和测试您的项目。在

更新：如果同时在主机上运行测试，则可能需要删除容器中不可写的python和pytest缓存。在主机运行时：

rm -rf .cache/ && find . -name __pycache__  | xargs rm -rf

Answer 2

老实说，对于docker这样的东西来说，这似乎是一个很好的用例。当然，仅仅使用python并不能完全干净地处理它，但是您可以随心所欲地滥用主机操作系统，而不必担心长期的损害。另外，与许多CI解决方案不同，它可以在您的开发机器上轻松运行。在

另外请注意，无论代码是否有意恶意，保持这种隔离仍有助于防止以下事故：

rm -rf /usr/local/share/ myapp