Dear Debian Security Team / Maintainer,
Security: likely local only, world writeable PID file,
umask(0), possibly (unknown?) additional issues?
Probably (quite?) minor security issue, also
(unconfirmed) issue may be masked by those using systemd.
Likely issue from upstream (not confirmed),
Likely from at least Version: 2.0.21-5.1 through
most current Debian Version (2.0.31) as this is being
submitted.
Would appear to come from, e.g.:
uwsgi-2.0.21/core/utils.c:162:          umask(0);
uwsgi-2.0.28/core/utils.c:162:          umask(0);
uwsgi-2.0.31/core/utils.c:162:          umask(0);
Further details (including (partial?) work-arounds) below:

Dear Maintainer,

What led up to the situation?

Encountered, e.g. (may be reformatted a bit):
# /etc/init.d/mailman3-web stop
Stopping Mailman3-web uWSGI service:
mailman3-webstart-stop-daemon: matching on world-writable
pidfile /run/mailman3-web/mailman3-web.pid is insecure
 failed!
#

Analyzed and tracked issue back (strace, etc.):
$ stat -c '%a %u %g %F %n' \
666 0 0 regular file /run/mailman3-web/mailman3-web.pid
$
/etc/init.d/mailman3-web -->
start-stop-daemon -->
/usr/bin/uwsgi_python3 --ini /etc/mailman3/uwsgi.ini \
--pidfile /run/mailman3-web/mailman3-web.pid --daemonize \
/var/log/mailman3/web/mailman-web.log
/usr/bin/uwsgi_python3 -->
/etc/alternatives/uwsgi_python3 -->
/usr/bin/uwsgi-core:
umask(000)
openat(... /run/mailman3-web/mailman3-web.pid
uwsgi-core (e.g. 2.0.21-5.1) -->
src:uwsgi, e.g.:
uwsgi-2.0.21/core/utils.c:162:          umask(0);
uwsgi-2.0.28/core/utils.c:162:          umask(0);
uwsgi-2.0.31/core/utils.c:162:          umask(0);

What exactly did you do (or not do) that was effective (or
ineffective)?

(partial?) Work-around?  Haven't fully tested,
but looks like if the PID file already exists, it won't
change permissions on the file, so I'll likely implement a
local work-around in the /etc/init.d/mailman3-web file.
Also, unconfirmed, but folks using systemd might not bump
into this issue, but regardless, the security issue would
appear to still be present in src:uwsgi uwsgi-core
and given the umask(0) in src:uwsgi, there may possibly be
additional security issues/risks.
Looking at recursive rdepends for uwsgi-core it's
possible/likely security issue(s) may also be exposed via
other packages.

What was the outcome of this action?

Existing does or may fail to properly stop due to insecure
PID file, and insecure PID file is also security issue.
Insecure umask may also have other risks, etc.
Work-arounds may be effective, those using systemd
might also not encounter this issue.

What outcome did you expect instead?
Was expecting PID file to be sufficiently secure,
and nominal stop actions to run successfully.

Note also: system is almost entirely Debian 13 stable
trixie, but at present still have some packages pinned to
Debian 12 oldstable bookworm, notably as some mailman3-web
related packages very seriously failed to work on Debian 13
when upgraded.  Have been whittling it down as feasible,
but at present only and exactly these packages are pinned
(Pin-Priority 995) to bookworm{,-{updates,security}}:
mailman3-web python3-django python3-django-allauth
python3-django-compressor python3-django-extensions
python3-django-hyperkitty python3-django-mailman3
python3-django-postorius python3-djangorestframework
python3-mistune uwsgi-core uwsgi-plugin-python3

Note also: until quite recently system was on systemd,
but very recently switched to sysvinit due to unrelated
systemd issues upon Debian 12 --> 13 upgrade (notably
systemd grossly failed to properly initialized network - had
been fine on 12, but not at all on 13, removed systemd and
went to sysvinit, then all the networking was fine again).

In addition to system described below,
same issue seen/reproduced on others.
Appears in common to be src:uwsgi uwsti-core,
and systemd may mask (but not eliminate) the issue.

My successfully tested workaround
(at least covering use under mailman3-web):

$ diff -U 4 /etc/init.d/mailman3-web{.BAK,}
--- /etc/init.d/mailman3-web.BAK        2019-06-07 18:03:29.000000000 +0000
+++ /etc/init.d/mailman3-web    2026-02-19 04:42:45.000000000 +0000
@@ -33,8 +33,14 @@
 do_start () {
     start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON \
         --test >/dev/null|| return 1

+    # https://bugs.debian.org/1128380 work-around:
+    if [ -f $PIDFILE ]; then
+        chmod o-w $PIDFILE
+    else
+        (umask 022 && >> $PIDFILE)
+    fi
     start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON \
         -- $DAEMON_ARGS || return 2
 }

$

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

systemd users are clearly not concerned, not using pidfiles in default
conf.

Conclusion: I think mailman3-web needs fixing, maybe removing exiting pidfiles
before starting uwsgi, or using start-stop-daemon --remove-pidfile. But I'm
open to discussions, maybe looking at chmod'ing existing pidfiles at uwsgi
startup.

Thanks,

Alex

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 \
[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\(' \
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.

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.

Yes, for those using systemd it might partially or entirely mask the
issue.

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.

Hi,

It's a combination of --pidfile and --daemonize that is required to trigger
the problem.

Workaround is to use --umask.

Ack, I proposed a fix upstream.

Thanks,

Alex

Security (team) bits:

Your / security team's call as to patching for Debian,
notably stable and oldstable (and sid too).

I note may be a while before upstream gets around to it:
https://uwsgi-docs.readthedocs.io/en/latest/
Note: The project is in maintenance mode (only bugfixes and
updates for new languages apis). Do not expect quick
answers on github issues and/or pull requests (sorry for
that) A big thanks to all of the users and contributors
since 2009.

I'm almost inclined to think ought be done and promptly,
notably as the source change is highly minimal, and yes, it
is a security bug/fix.  But given its likely quite low
impact, and also significant numbers of reverse
dependencies, and thus possibility of introducing unintended
regression bug, perhaps a meet in the middle?  E.g. get it
into sid, it naturally progresses to testing, it goes into
testing for some reasonable time (2 weeks?) with no reported
regressions, then line it up for proposed-updates -->
udpates --> next scheduled point release for stable and
oldstable.

Anyway, just my thoughts on the matter.
Totally y'all's call to make on that.

Much thanks in all regards for your work on it and
consideration, etc.!

Further details and reference bits:
Looks good!
Thanks, nice catch!  And tested, confirmed works,
and that does make for cleaner work-around (at least for
mailman3-web's use of uwsgi[-core]):
$ (cd /var/cache/apt/archives &&
--- -   2026-02-22 13:58:31.788852520 +0000
+++ /etc/init.d/mailman3-web    2026-02-22 13:57:59.000000000 +0000
@@ -20,4 +20,6 @@
 LOGFILE="/var/log/mailman3/web/mailman-web.log"
 DAEMON_ARGS="--ini /etc/mailman3/uwsgi.ini --pidfile ${PIDFILE}
--daemonize ${LOGFILE}"
+# https://bugs.debian.org/1128380 uwsgi[-core] work-around:
+DAEMON_ARGS="${DAEMON_ARGS:+$DAEMON_ARGS }--umask 022"

 test -x $DAEMON || exit 0
$

We believe that the bug you reported is fixed in the latest version of
uwsgi, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1128380@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alexandre Rossi <niol@zincube.net> (supplier of updated uwsgi package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 22 Feb 2026 18:17:03 +0100
Source: uwsgi
Architecture: source
Version: 2.0.31-3
Distribution: unstable
Urgency: medium
Maintainer: uWSGI packaging team <pkg-uwsgi-devel@lists.alioth.debian.org>
Changed-By: Alexandre Rossi <niol@zincube.net>
Closes: 934731 1128380
Changes:
 uwsgi (2.0.31-3) unstable; urgency=medium
 .
   * -dbgsym migration now done
   * uwsgi-extra is Multi-Arch foreign
   * autopkgtest: fix test_mountpoints not run
   * fix pidfile default permissions (Closes: #934731, #1128380)
Checksums-Sha1:
 72d2b3e87661d21a795d8c603e580ab14c4d7d11 3453 uwsgi_2.0.31-3.dsc
 2ab3d3757c9a0a8cdcc6fd176f9fc9de82179488 57316 uwsgi_2.0.31-3.debian.tar.xz
 c0fcbcff4b2fe46499f90f8fa2b716e94b131b75 17396 uwsgi_2.0.31-3_amd64.buildinfo
Checksums-Sha256:
 ea7b019ae9adebcfb6217bfb97d93fe1f035d15f05a61f58a716db22e76c32fc 3453 uwsgi_2.0.31-3.dsc
 c5fe6cd3d6264e715e1c8578d8491106a89e924f87b7edbca13a01e72cf69f48 57316 uwsgi_2.0.31-3.debian.tar.xz
 9197f492b1feb8246911d38dce38cc9a33d75a0e8572a1da004339b0e7c39ecd 17396 uwsgi_2.0.31-3_amd64.buildinfo
Files:
 28e733246cdee56097c0dd2a0f982ee4 3453 httpd optional uwsgi_2.0.31-3.dsc
 67782ede4e7b92efddbc29657af79d55 57316 httpd optional uwsgi_2.0.31-3.debian.tar.xz
 2728e5901e4d8f0addff140080b23e01 17396 httpd optional uwsgi_2.0.31-3_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmmrNaYWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICO/gD/9aDBJydVT4gPRdLAP+4lnfbskr
oEyILWUlrcMxr+6GKDcX9ym0CYh+AGLkcqcQ6RatTJw33iXmy80iahT5IUjSXrVf
592qGcR9lHByURQOGeJQvA/QP3clV5f6XP3tdp0WiXkwSO328ypIKrCMC/rrmvz7
kCa8yBfE9U6Juki0ZvYo3ct2JJsbGFhUnMsssjN5mdcOjBYv8Z4mUWmBg3sFJHrK
Potr9EbloxROdQH2m6hpy7Iop13mxXx2oT+p9QYakDyhpHZn1hIMIbtGIQ4NpnSj
DCIERyLuo9IwWw422syd73a16v84ozysZll6xttM4BML233yH9764pAqZbHK7hwe
vwo1h/obADkwTriBahjY1TG8F5tSXdk3w/TKIN1bDTw4sG1CulVob3o9d9rzd8ma
IC9tkR8mf1tFLvqwkr6+Uh4AfGij9XP0Alu0eX8MJf7c8U9oII42WfuBovaTNXn4
MK881OGx/fxT5we3j4ncdYuaVc/8E+OFI+R1pUVmjv+BOF/HN/kXFvvlvP7aaMrc
n2wOm5rfQWvDeumZCXlRtwJgG5ZZXGYhUj1p8c3ynlBoUfzyvBLpcwxye6vjTlwE
UVzduvPz1DpVjwRn8zbhS04Etn4lpEKqW2rqayZpmul2JbrfgAeuVOko7iRz8e5t
mmo5yLRVs+2d1UP7LQ==
=Z5xe
-----END PGP SIGNATURE-----