我想使用uwsgi（由NGINX提供）从Django应用程序写入一个文件夹。我将该文件夹的所有权设置为root:writinggroup，并将该文件夹的权限设置为775.我将www-data用户添加到论坛writinggroup。
然后在我的uwsgi ini文件中，我设置：
uid = www-data
但是当我运行我的服务器并点击相应的URL来触发写操作时，我收到了权限错误。
但如果我将文件夹的所有权转换为www-data:writinggroup，一切都会完美无缺。
那么这里发生了什么？为什么将文件夹的用户所有者设置为www-data才能完成工作，而将文件夹的组所有者设置为writinggroup并不是www-data （用户）是该组的成员吗？
基本上，我要问的是：如果你在uwsgi配置中设置uid而不是gid，为什么uwsgi进程的行为就像它继承了与uid所属的组相关联的权限？ / p>
答案 0 :(得分：1)
跟进dgel建议学习Unix权限：当你在Unix中运行进程时，基本上有3种方法可以被操作系统视为“绿色点亮”权限。
3号很重要。这是很多磁盘操作最终是绿灯的。即用户joe是群组awesome的成员。文件夹important归root:awesome所有，权限为775.您在终端执行命令joe，尝试写入important。这将与用户joe一起运行，并且可能与有效的组ID joe（即仅包含用户joe的组）一起运行。独自一人，这不会完成任务。但由于joe位于awesome且awesome，该组具有写入权限，因此您的命令可以成功。
当你在emperror模式下运行uWSGI时，你可以为你的vassal进程设置一个uid和gid。我曾假设这将导致具有上述3种类型权限的附庸。但那不太对劲。虽然附庸确实使用您指定的有效用户ID和有效组ID运行，但他们不结束与其进程相关联的任何补充组ID。
所以说你有uWSGI与uid=www-data和gid=www-data一起运行，你想写到上面描述的important文件夹。因此，您www-data成为awesome的成员。这不就足够了，因为附庸流程只有 用户www-data和www-data群组的权限而不是 www-data（用户）所属的组的权限...即不将继承awesome组的权限。这导致在将用户切换到www-data之后在终端处执行的命令可能成功的烦人行为，而由上面配置的uWSGI进程运行的代码将失败（因为在终端处该命令获得{{1的权限）分组，但附庸没有）。
一种解决方案是将awesome文件夹的所有权更改为important。但我讨厌这个答案，因为它没有推广到多个用户可能需要这种访问的情况。相反，有一种更好的方法：uWSGI有www-data:awesome选项。所以你需要指定：
add-gid。此参数可以设置多次，以便您可以根据心脏需要将尽可能多的补充组与您的附庸过程相关联。您可以在uWSGI发行说明here中阅读相关内容。
一个非常重要的注意事项是此参数仅在uWSGI 1.9.15中添加。这比
uid = www-data
gid = www-data
add-gid = awesome
快速服务器重启（sudo mv /usr/bin/uwsgi /usr/bin/uwsgi.bak
sudo pip install -U uwsgi
sudo ln -fs /usr/local/bin/uwsgi /usr/bin/uwsgi
），我已经完成了设置！