1đź‘Ť
Following up on dgel’s suggestion to learn about Unix permissioning: when you run processes in Unix, there are basically 3 ways you can wind up being “green lit” permissions-wise by the OS.
- The user calling the command can be user-permissioned for the disk operation (green-lit because of effective user id)
- The group id associated with the process can be group-permissioned for the disk operation (green-lit because of effective group id)
- The user calling the command can be a member of a group that is group-permissioned for the disk operation (green-lit because of supplementary group id)
Number 3 there is important. It’s how a lot of disk operations are ultimately green-lit. I.e. user joe is a member of group awesome. Folder important is owned by root:awesome with permissions 775. You execute a command at the terminal as joe where you try to write to important. This will be run with user joe and likely with effective group id joe (i.e. the group that contains only the user joe). Alone, this wouldn’t get the job done. But because joe is in awesome and awesome the group has write permissions, your command is able to succeed.
When you run uWSGI in emperror mode, you can set a uid and gid for your vassal processes. I had assumed that this would result in vassals with the 3 types of permissions described above. But that’s not quite right. While the vassals do indeed run with the effective user ID and effective group ID you specify, they do not wind up with any supplementary group ID’s associated to their processes.
So say you have uWSGI running with uid=www-data and gid=www-data and you want to write to the important folder described above. So you make www-data a member of awesome. This will not be sufficient, because the vassal process will have only the permissions of www-data the user and www-data the group and not the permissions of the groups to which www-data (the user) belongs…i.e. it will not inherit the permissions of the awesome group. This leads to the annoying behavior that commands executed at the terminal after switching users to www-data may succeed while code run by the above-configured uWSGI process will fail (because at the terminal the command gets the permissions of the awesome group, but the vassals do not).
One solution would be to change the ownership of the important folder to be www-data:awesome. But I hate that answer since it doesn’t generalize to a case where multiple users might need this kind of access. Instead, there’s a better way: there is an add-gid option for uWSGI. So you would need to specify:
uid = www-data
gid = www-data
add-gid = awesome
in your uWSGI configuration. This parameter can be set many times so that you can associate as many supplementary groups with your vassal processes as your heart desires. You can read about it in the uWSGI release notes here.
A very important note is that this parameter was only added in uWSGI 1.9.15. This is much newer than the version that ships with Ubuntu. So if you (like me) are in that situation, you’ll need to upgrade uWSGI. I did that with:
sudo mv /usr/bin/uwsgi /usr/bin/uwsgi.bak
sudo pip install -U uwsgi
sudo ln -fs /usr/local/bin/uwsgi /usr/bin/uwsgi
Quick server reboot (sudo service uwsgi restart) and I was all set!