为什么从virtualenv运行的Django无法写入该路径？

Question

我们的客户机有一个web应用程序，在Ubuntu服务器上运行virtualenv的Django实例。我们对该服务进行了安全审计，并在文件上载表单中发现了一个路径遍历漏洞，允许攻击者在django用户拥有的路径中写入任意文件。示例：

参数“Import Name”随值一起提供

../some/path/to/create

然后为form file字段提供任意的filename和正确的文件内容

然后应用程序执行

try:
    path = os.path.join(DEFAULT_UPLOAD_DIR, <Import Name>)
    os.mkdir(path)
    ...
    with open(os.path.join(path, <Filename From Form>)) as upload_file:
        upload_file.write(<File Contents>)
    ...

不安全的os.path.join允许攻击者进入目录树并上传到DEFAULT_UPLOAD_DIR以外的其他目录。因此，基本上如果攻击者能够找到服务器上还不存在的路径，他就能够创建该文件夹，避免try...except中的os.mkdir()失败，并将文件上载到那里。你知道吗

现在，如果攻击者能够写入

../virtualenvs/<env name>/lib/python2.7/

由于Django模块是从virtualenv python目录下的子目录site-packages加载的，pythonpath告诉我们直接在lib/python2.7下的任何模块都会首先加载，因此模块加载顺序基本上允许攻击者“覆盖”模块，并确保在导入时运行其代码。你知道吗

我们做了概念验证渗透测试并写信给

../virtualenvs/somepath/__init__.py

但由于某种原因我们无法写信给

../virtualenvs/<actual env name>/

这很奇怪，因为权限与somepath完全相同，所有者/组在这两种情况下都是Django用户。为Django用户启用virtualenv并转到pythonshell，它允许我进行写操作，因此当从易受攻击的窗体视图调用它时，它不能这样做似乎很奇怪。你知道吗

问题是：Django实例运行的virtualenv路径是否有什么特殊的地方使它无法写入该路径？还是我遗漏了什么？你知道吗