uWSGI doesn't switch to defined user uid=my_user in custom uwsgi.ini file

Question

I am running uwsgi 2.0.17.1, nginx/1.12.2 and flask 1.0.2 to run a custom API on Centos 7. Everything works perfect except that the processes are owned by the uwsgi user while I explicitly defined in my custom .ini file to use a different user than uwsgi This is the default uwsgi ini file located in /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

And this is the content of my custom .ini file

[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

And if I run the command 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

You notice it's working properly without errors, but when I check htop I see the following:

So despite the face that I specify uid and gid in my_app.ini, uwsgi still run the processes as uwsig.

When I change those variables

uid = uwsgi gid = uwsgi

in the main /etc/uwsgi.ini to be like

uid=svc.my_api
gid=svc.my_api

it doesn't work and I get the following output of 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...

So my question is: does anyone know why it uwsgi still runs under uwsgi user and how can I make the use svc.my_app to own the process of uwsgi?

UPDATE 23/10/2018 Based on the comment from @Kamil Niski I tried to run uWSGI as root. When I replaced uwsgi with root in /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.

It didn't work and I get the following error:

-- 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.

Answer 1

I managed to run uWSGI under svc.my_api after changing the ownership of the following directories:

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/

and by editing the /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

Setting emperor-tyrant to false have solved the problem! Why disabling the emperor-tyrant would solve the problem? Because The emperor-tyrant option if it's on as it sets uid/gid for every process based on the owner of the related .ini config file.

Sources:

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

Answer 2

The uwsgi documentation gives you a hint on what might be wrong.

The emperor is normally run as root, setting the UID and GID in each instance’s config. The vassal instance then drops privileges before serving requests. In this mode, if your users have access to their own uWSGI configuration files, you can’t trust them to set the correct uid and gid. You could run the emperor as unprivileged user (with uid and gid) but all of the vassals would then run under the same user, as unprivileged users are not able to promote themselves to other users.

This means you should run emperor as root and then vassals privileges should be dropped as expected.