uWSGI не переключается на определенного пользователя uid=my_user в пользовательском файле uwsgi.ini

Я запускаю uwsgi 2.0.17.1, nginx/1.12.2 и flask 1.0.2 для запуска пользовательского API на Centos 7. Все работает идеально, за исключением того, что процессы принадлежат пользователю uwsgi, в то время как я явно определил в своем пользовательском файле .ini использовать пользователя, отличного от uwsgi. Это файл uwsgi ini по умолчанию, расположенный в /etc/uwsgi.ini.

[uwsgi]
uid = uwsgi
gid = uwsgi
pidfile = /run/uwsgi/uwsgi.pid
emperor = /etc/uwsgi.d
stats = /run/uwsgi/stats.sock
chmod-socket = 660
emperor-tyrant = true
cap = setgid,setuid

И это содержимое моего пользовательского файла .ini

[uwsgi]

chdir = /var/www/my_api/current
virtualenv = /var/www/my_api/current/my_api_virtualenv
module = wsgi
plugin = python36u
wsgi-file= wsgi.py
uid=svc.my_api
gid=svc.my_api
master = true
processes = 2
enable-threads = true
need-app=true
logto =/var/www/my_api/logs/my_api.log
socket =127.0.0.1:9090
vacuum = true
die-on-term = true

И если я запускаю команду sudo systemctl status uwsgi

● uwsgi.service - uWSGI Emperor Service
   Loaded: loaded (/usr/lib/systemd/system/uwsgi.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2018-10-19 11:47:01 CEST; 9s ago
 Main PID: 20038 (uwsgi)
   Status: "The Emperor is governing 1 vassals"
   CGroup: /system.slice/uwsgi.service
           ├─20038 /usr/sbin/uwsgi --ini /etc/uwsgi.ini
           ├─20039 /usr/sbin/uwsgi --ini /etc/uwsgi.ini
           ├─20040 /usr/sbin/uwsgi --ini my_api.ini
           ├─20043 /usr/sbin/uwsgi --ini my_api.ini
           └─20044 /usr/sbin/uwsgi --ini my_api.ini

Oct 19 11:47:01 my_server.local uwsgi[20038]: *** Operational MODE: no-workers ***
Oct 19 11:47:01 my_server.local uwsgi[20038]: spawned uWSGI master process (pid: 20038)
Oct 19 11:47:01 my_server.local uwsgi[20038]: [emperor-tyrant] dropping privileges to 997 995 for instance my_api.ini
Oct 19 11:47:01 my_server.local uwsgi[20038]: *** Stats server enabled on /run/uwsgi/stats.sock fd: 7 ***
Oct 19 11:47:01 my_server.local uwsgi[20038]: *** has_emperor mode detected (fd: 7) ***
Oct 19 11:47:01 my_server.local uwsgi[20038]: [uWSGI] getting INI configuration from my_api.ini
Oct 19 11:47:03 my_server.local uwsgi[20038]: Fri Oct 19 11:47:03 2018 - [emperor] vassal my_api.ini has been spawned
Oct 19 11:47:03 my_server.local uwsgi[20038]: Fri Oct 19 11:47:03 2018 - [emperor] vassal my_api.ini is ready to accept requests
Oct 19 11:47:03 my_server.local uwsgi[20038]: Fri Oct 19 11:47:03 2018 - [emperor] vassal my_api.ini is now loyal
Oct 19 11:47:03 my_server.local uwsgi[20038]: Fri Oct 19 11:47:03 2018 - [emperor] vassal my_api.ini is now loyal

Вы заметили, что он работает правильно, без ошибок, но когда я проверяю htop, я вижу следующее: вывод htop, отфильтрованный на uwsgi

Итак, несмотря на то, что я указал uid и gid в my_app.ini, uwsgi все равно запускает процессы как uwsig.

Когда я меняю эти переменные

uid = uwsgi gid = uwsgi

в основном /etc/uwsgi.ini быть похожим

uid=svc.my_api
gid=svc.my_api

это не работает, и я получаю следующий вывод sudo systemctl status uwsgi

● uwsgi.service - uWSGI Emperor Service
   Loaded: loaded (/usr/lib/systemd/system/uwsgi.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2018-10-19 12:03:23 CEST; 309ms ago
 Main PID: 20118 (uwsgi)
   Status: "uWSGI is ready"
   CGroup: /system.slice/uwsgi.service
           └─20118 /usr/sbin/uwsgi --ini /etc/uwsgi.ini

Oct 19 12:03:23 my_server.local uwsgi[20118]: your memory page size is 4096 bytes
Oct 19 12:03:23 my_server.local uwsgi[20118]: detected max file descriptor number: 1024
Oct 19 12:03:23 my_server.local uwsgi[20118]: lock engine: pthread robust mutexes
Oct 19 12:03:23 my_server.local uwsgi[20118]: thunder lock: disabled (you can enable it with --thunder-lock)
Oct 19 12:03:23 my_server.local uwsgi[20118]: your mercy for graceful operations on workers is 60 seconds
Oct 19 12:03:23 my_server.local uwsgi[20118]: *** Operational MODE: no-workers ***
Oct 19 12:03:23 my_server.local uwsgi[20118]: spawned uWSGI master process (pid: 20118)
Oct 19 12:03:23 my_server.local uwsgi[20118]: error removing unix socket, unlink(): Permission denied [core/socket.c line 198]
Oct 19 12:03:23 my_server.local uwsgi[20118]: bind(): Address already in use [core/socket.c line 230]
Oct 19 12:03:23 my_server.local uwsgi[20118]: waiting for Emperor death...

Итак, мой вопрос: кто-нибудь знает, почему uwsgi все еще работает под пользователем uwsgi и как я могу использовать svc.my_app для владения процессом uwsgi?

ОБНОВЛЕНИЕ 23.10.2018 На основании комментария @Kamil Niski я попытался запустить uWSGI от имени пользователя root. Когда я заменил uwsgi на root в /etc/uwsgi.ini

[uwsgi]
uid = root
gid = root
pidfile = /run/uwsgi/uwsgi.pid
emperor = /etc/uwsgi.d
stats = /run/uwsgi/stats.sock
chmod-socket = 660
emperor-tyrant = true
cap = setgid,setuid.

Это не сработало, и я получаю следующую ошибку:

-- Subject: Unit uwsgi.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit uwsgi.service has failed.
--
-- The result is failed.
Oct 23 14:13:08 my_server.local systemd[1]: Unit uwsgi.service entered failed state.
Oct 23 14:13:08 my_server.local systemd[1]: uwsgi.service failed.
Oct 23 14:13:09 my_server.local systemd[1]: uwsgi.service holdoff time over, scheduling restart.
Oct 23 14:13:09 my_server.local systemd[1]: Starting uWSGI Emperor Service...
-- Subject: Unit uwsgi.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit uwsgi.service has begun starting up.
Oct 23 14:13:09 my_server.local uwsgi[32290]: [uWSGI] getting INI configuration from /etc/uwsgi.ini
Oct 23 14:13:09 my_server.local uwsgi[32290]: setting capability setgid [6]
Oct 23 14:13:09 my_server.local uwsgi[32290]: setting capability setuid [7]
Oct 23 14:13:09 my_server.local uwsgi[32290]: *** Starting uWSGI 2.0.17.1 (64bit) on [Tue Oct 23 14:13:09 2018] ***
Oct 23 14:13:09 my_server.local uwsgi[32290]: compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-28) on 09 July 2018 03
Oct 23 14:13:09 my_server.local uwsgi[32290]: os: Linux-3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018
Oct 23 14:13:09 my_server.local uwsgi[32290]: nodename: my_server.local
Oct 23 14:13:09 my_server.local uwsgi[32290]: machine: x86_64
Oct 23 14:13:09 my_server.local uwsgi[32290]: clock source: unix
Oct 23 14:13:09 my_server.local uwsgi[32290]: pcre jit disabled
Oct 23 14:13:09 my_server.local uwsgi[32290]: detected number of CPU cores: 2
Oct 23 14:13:09 my_server.local uwsgi[32290]: current working directory: /
Oct 23 14:13:09 my_server.local uwsgi[32290]: writing pidfile to /run/uwsgi/uwsgi.pid
Oct 23 14:13:09 my_server.local uwsgi[32290]: detected binary path: /usr/sbin/uwsgi
Oct 23 14:13:09 my_server.local uwsgi[32290]: *** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
Oct 23 14:13:09 my_server.local uwsgi[32290]: your processes number limit is 15030
Oct 23 14:13:09 my_server.local uwsgi[32290]: your memory page size is 4096 bytes
Oct 23 14:13:09 my_server.local uwsgi[32290]: detected max file descriptor number: 1024
Oct 23 14:13:09 my_server.local systemd[1]: uwsgi.service: main process exited, code=exited, status=1/FAILURE
Oct 23 14:13:09 my_server.local uwsgi[32290]: lock engine: pthread robust mutexes
Oct 23 14:13:09 my_server.local systemd[1]: Failed to start uWSGI Emperor Service.
-- Subject: Unit uwsgi.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit uwsgi.service has failed.
--
-- The result is failed.
Oct 23 14:13:09 my_server.local uwsgi[32290]: *** starting uWSGI Emperor ***
Oct 23 14:13:09 my_server.local systemd[1]: Unit uwsgi.service entered failed state.
Oct 23 14:13:09 my_server.local uwsgi[32290]: [emperor-tyrant] dropping privileges to 1004 1004 for instance my_api.ini
Oct 23 14:13:09 my_server.local systemd[1]: uwsgi.service failed.
Oct 23 14:13:09 my_server.local uwsgi[32290]: thunder lock: disabled (you can enable it with --thunder-lock)
Oct 23 14:13:09 my_server.local uwsgi[32290]: cap_set_proc(): Operation not permitted [core/utils.c line 301]
Oct 23 14:13:09 my_server.local systemd[1]: uwsgi.service holdoff time over, scheduling restart.
Oct 23 14:13:09 my_server.local systemd[1]: start request repeated too quickly for uwsgi.service
Oct 23 14:13:09 my_server.local systemd[1]: Failed to start uWSGI Emperor Service.
-- Subject: Unit uwsgi.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit uwsgi.service has failed.
--
-- The result is failed.
Oct 23 14:13:09 my_server.local systemd[1]: Unit uwsgi.service entered failed state.
Oct 23 14:13:09 my_server.local systemd[1]: uwsgi.service failed.

person Peshmerge    schedule 19.10.2018    source источник


Ответы (2)


Мне удалось запустить uWSGI под svc.my_api после смены владельца следующих каталогов:

chown -R svc.my_api:svc.my_api /etc/uwsgi.d/

chown svc.my_api:svc.my_api /etc/uwsgi.ini

chown -R svc.my_api:svc.my_api /run/uwsgi/

и отредактировав /etc/uwsgi.ini

[uwsgi]
uid = svc.my_api
gid = svc.my_api
pidfile = /run/uwsgi/uwsgi.pid
emperor = /etc/uwsgi.d
stats = /run/uwsgi/stats.sock
chmod-socket = 660
emperor-tyrant = false
cap = setgid,setuid

Установка императора-тирана на false решила проблему! Почему отключение императора-тирана решит проблему? Потому что опция «император-тиран», если она включена, устанавливает uid/gid для каждого процесса в зависимости от владельца соответствующего конфигурационного файла .ini.

Источники:

https://chriswarrick.com/blog/2016/02/10/deploying-python-web-apps-with-nginx-and-uwsgi-emperor/

&

https://uwsgi-docs.readthedocs.io/en/latest/Emperor.html#tyrant-mode-secure-multi-user-hosting

person Peshmerge    schedule 23.10.2018
comment
Я не уверен, что это то, что вы хотели. Но если это решит вашу проблему, то все в порядке. Я советовал вам запустить процесс Emperor под пользователем root и всеми вассалами в качестве непривилегированного пользователя. - person Kamil Niski; 23.10.2018
comment
Теперь процессы uwsgi для my_app.ini выполняются под svc.my_api, и это то, что мне было нужно. Но я должен признать, что есть много вещей, которых я не понимаю, и я чувствую, что должен провести некоторые эксперименты, чтобы понять это лучше. Но на данный момент получил то, что мне было нужно! Спасибо, Камил. - person Peshmerge; 23.10.2018

Документация uwsgi дает вам подсказку о том, что может быть не так.

Император обычно запускается от имени пользователя root, устанавливая UID и GID в конфигурации каждого экземпляра. Затем вассальный экземпляр сбрасывает привилегии перед обслуживанием запросов. В этом режиме, если ваши пользователи имеют доступ к своим собственным файлам конфигурации uWSGI, вы не можете доверять им в установке правильных uid и gid. Вы можете запустить императора как непривилегированного пользователя (с uid и gid), но тогда все вассалы будут работать под одним и тем же пользователем, так как непривилегированные пользователи не могут повышать свою квалификацию до других пользователей.

Это означает, что вы должны запустить Emperor как root, а затем привилегии вассалов должны быть сброшены, как и ожидалось.

person Kamil Niski    schedule 19.10.2018
comment
Спасибо, Камиль, но, как вы видите, в моем файле my_app.ini я указываю, какие пользователи должны быть у вассала (uid и gid), но он по-прежнему работает как root, хотя я ожидаю, что это не так, как описано в документации. - person Peshmerge; 23.10.2018
comment
@Peshmerge Но вы не работаете как root. Вы показываете в htop и в uwsgi.ini, что используете uwsgi пользователя. Emperor должен работать как root, а не uwsgi. Тогда он сможет корректно сбрасывать привилегии. - person Kamil Niski; 23.10.2018
comment
Я не трогал файл /etc/uwsgi.ini. Я просто поменяю и посмотрю, что будет! - person Peshmerge; 23.10.2018
comment
изменение uid и gid в /etc/uwsgi.ini на root не помогло остановить сервер uwsgi. Возврат к uwsgi заставляет его работать нормально! - person Peshmerge; 23.10.2018