The issue is uwsgi[-core] at least with it insecurely
creating the PID file. It explicitly calls umask(0),
changing the umask to 0[00] before creating the PID file.
It may also be setting explicit (0666) permissions when it
creates the PID file. That's what triggers the problem(s).
What I put in /etc/init.d/mailman3-web is just a
work-around for issue in uwsgi[-core], to mitigate it
otherwise impacting mailman3-web. The issue in
uwsgi[-core] may have security and other impacts beyond
mailman3-web.
# rm /run/mailman3-web/mailman3-web.pid
# umask
0022
# /usr/bin/uwsgi_python3 --ini /etc/mailman3/uwsgi.ini \
> --pidfile /run/mailman3-web/mailman3-web.pid \
> --daemonize /var/log/mailman3/web/mailman-web.log
[uwsgi] implicit plugin requested python3
[uWSGI] getting INI configuration from /etc/mailman3/uwsgi.ini
# ls -ld /run/mailman3-web/mailman3-web.pid
-rw-rw-rw- 1 root root 5 Feb 19 18:00 /run/mailman3-web/mailman3-web.pid
# chmod o-w /run/mailman3-web/mailman3-web.pid
# cat /run/mailman3-web/mailman3-web.pid
2375
# ps lwwwp 2375
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 33 2375 1 20 0 86428 76912 do_epo S ?
0:18 /usr/bin/uwsgi_python3 --ini /etc/mailman3/uwsgi.ini --pidfile
/run/mailman3-web/mailman3-web.pid --daemonize
/var/log/mailman3/web/mailman-web.log
# /etc/init.d/mailman3-web stop
Stopping Mailman3-web uWSGI service: mailman3-web.
# ps lwwwp 2375
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
# rm /run/mailman3-web/mailman3-web.pid
# strace -fv -e trace=umask,openat -s2048 /usr/bin/uwsgi_python3 --ini
/etc/mailman3/uwsgi.ini --pidfile /run/mailman3-web/mailman3-web.pid
--daemonize /var/log/mailman3/web/mailman-web.log 2>&1 | sed -ne
'/umask/h;/openat.*\.pid/{H;x;p;q}'[pid 2947] umask(000)
= 022
openat(AT_FDCWD, "/run/mailman3-web/mailman3-web.pid",
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
#
As you can see, despite being invoked with a umask of 022,
the binary changes the umask to 0[00] before creating the
PID file, and may also explicitly set permissions when it
creates the file, thus it world writable PID file. The
work-around I implemented creates the PID file with
reasonably sane permissions (notably not world writable)
before uwsgi[-core] calls umask(0) and openat(2),
but that's only covering the case of mailman3-web PID file,
it doesn't address uwsgi[-core] issue more generally.
Generally isn't good reason for any program to be setting
umask to 0 and/or otherwise creating world writable files
(security, etc.).
Here we have it in the source:
$ find */ -type f -exec fgrep -C 1 -n -e 'umask(0' -e
'uwsgi.do_not_change_umask' \{\} /dev/null \;
uwsgi-2.0.31/core/uwsgi.c-4344-
uwsgi-2.0.31/core/uwsgi.c:4345: uwsgi.do_not_change_umask = 1;
uwsgi-2.0.31/core/uwsgi.c-4346-}
uwsgi-2.0.31/core/utils.c-160-
uwsgi-2.0.31/core/utils.c:161: if (!uwsgi.do_not_change_umask) {
uwsgi-2.0.31/core/utils.c:162: umask(0);
uwsgi-2.0.31/core/utils.c-163- }
$
Perhaps it would be more fitting to change
uwsgi.do_not_change_umask to be set to 0.
I only find umask system call two places in the source:
$ find */ -type f -exec egrep -n -e '(^|[^_])umask\(' \
> \{\} /dev/null \;
uwsgi-2.0.31/core/uwsgi.c:4343: umask(mask);
uwsgi-2.0.31/core/utils.c:162: umask(0);
$
In case that other one might be the source of the issue.
Also possible the issue may come from open(3) or openat(2)
in the source, as I also notice:
openat(AT_FDCWD, "/run/mailman3-web/mailman3-web.pid",
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
Note that last parameter 0666 on the call, if that's
permissions, that's where issue could be coming for, at
least for the PID file.
Not sure the other (security, etc.) implications,
of not changing the umask there or setting it to something
more reasonable, but certainly it shouldn't generally be
operating with a umask of 0, and in any case, PID file
shouldn't be getting created world writable.
On Thu, Feb 19, 2026 at 8:51 AM Alexandre Rossi <[email protected]> wrote:
> uwsgi does not try to mess with umask of existing pidfiles. Should it? I'm
> not sure how this is used by external scripts... My guess is that scripts
> using uwsgi --pidfile should set umask as they wish and correctly cleanup
> left over pidfiles if uwsgi crashes.
Problem is when uwsgi creates the PID file, it creates it insecurely,
even if a secure umask is set before it's invoked.
My work-around pre-creates the PID file, as you're correct that
uwsgi doesn't change permissions on the file if it already exists.
> systemd users are clearly not concerned, not using pidfiles in default
> conf.
Yes, for those using systemd it might partially or entirely mask the
issue.
> Conclusion: I think mailman3-web needs fixing, maybe removing exiting pidfiles
Sorry, I beg to differ on that. It's uwsgi that's insecurely creating PID file.
mailman3-web is but one package that uses uwsgi[-core], and
uwsgi[-core] may similarly impact other packages. Shouldn't really have to play
whack-a-mole implementing work-around for uwsgi issue in ever package that
does or may come to use uwsgi. :-)
Thanks for your attention to this matter.
