uWSGI 进程不继承与其 uid 所属组关联的权限

Question

我有一个要使用 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 所属的组相关联的权限？

Answer 1

按照 dgel 的建议了解 Unix 权限：当您在 Unix 中运行进程时，基本上有 3 种方法可以让您最终获得操作系统的“绿灯”权限。

1. 调用该命令的用户可以获得磁盘操作的用户权限（由于有效的用户 ID 而亮绿灯）
2. 与进程关联的组 id 可以被组许可用于磁盘操作（绿灯是因为有效的组 id）
3. 调用该命令的用户可以是某个组的成员，该组具有磁盘操作的组权限（由于补充组 ID 而亮绿灯）

第三点很重要。这就是许多磁盘操作最终获得绿灯的方式。 IE。用户joe 是组awesome 的成员。文件夹important 由root:awesome 拥有，权限为775。您在终端上以joe 的身份执行命令，并尝试写入important。这将使用用户 joe 运行，并且可能使用有效组 ID joe（即仅包含用户 joe 的组）。独自一人，这将无法完成工作。但是因为joe在awesome和awesome组中有写权限，所以你的命令是可以成功的。

当你在 emperror 模式下运行 uWSGI 时，你可以为你的 vassal 进程设置一个 uid 和 gid。我曾假设这会导致附庸拥有上述 3 种权限。但这并不完全正确。虽然 vassal 确实使用您指定的有效用户 ID 和有效组 ID 运行，但它们最终不会使用与其进程关联的任何补充组 ID。

假设您使用uid=www-data 和gid=www-data 运行uWSGI，并且您想写入上述important 文件夹。所以你让www-data 成为awesome 的成员。这将不足够，因为附庸进程将仅拥有www-data用户和www-data组和不的权限www-data（用户）所属的组的权限...即它不会继承awesome 组的权限。这导致了令人讨厌的行为，即切换用户到www-data后在终端执行的命令可能会成功，而上面配置的uWSGI进程运行的代码会失败（因为在终端该命令获得了awesome组的权限，但封臣没有）。

一种解决方案是将important 文件夹的所有权更改为www-data:awesome。但我讨厌这个答案，因为它不能概括为多个用户可能需要这种访问的情况。相反，有一个更好的方法：uWSGI 有一个add-gid 选项。所以你需要指定：

uid = www-data
gid = www-data
add-gid = awesome

在你的 uWSGI 配置中。此参数可以设置多次，以便您可以根据自己的意愿将尽可能多的补充组与您的附庸进程相关联。您可以在 uWSGI 发行说明here 中了解它。

一个非常重要的注意是这个参数只在uWSGI 1.9.15中被添加。这比 Ubuntu 附带的版本更新得多。因此，如果您（像我一样）处于这种情况，则需要升级 uWSGI。我这样做了：

sudo mv /usr/bin/uwsgi /usr/bin/uwsgi.bak
sudo pip install -U uwsgi
sudo ln -fs /usr/local/bin/uwsgi /usr/bin/uwsgi

快速重启服务器 (sudo service uwsgi restart)，一切就绪！