NewInBullseye from wiki.debian.org tells us that:

"systemd now enables the fs.protected_fifos and fs.protected_regular
kernel parameters by default. This may break applications that share
files in /tmp (or other sticky directories) among multiple user accounts."

Setting fs.protected_regular=2, as seems to be the default in Devuan
Chimaera, can have interesting effects:

richard@prost:~$ touch /tmp/somefile
richard@prost:~$ su
Password:
root@prost:/home/richard# ls -al /tmp/
total 20
drwxrwxrwt  3 root    root    4096 May 29 10:47 .
drwxr-xr-x 22 root    root    4096 May 17 10:55 ..
drwxrwxrwt  2 root    root    4096 May 16 16:54 .ICE-unix
-rw-r--r--  1 richard richard    0 May 29 10:47 somefile
drwxrwxrwt  2 root    root    4096 May 16 16:54 .X11-unix
root@prost:/home/richard# echo "stuff" > /tmp/somefile
bash: /tmp/somefile: Permission denied

Huh? I can create a file in /tmp as a normal user that root cannot
modify. This surprises me, and I suspect it might surprise software
running on my systems.

------------------------------------------------------------------

Daniel Feuchtinger
(https://groups.google.com/g/linux.debian.bugs.dist/c/k-lbkGMPe3Y)
objected and asked the devs to try a users perspective:

"You try to write to a file and it does not work (funny: touch does work)
You check the file permissions
You check the extended attributes
You search for erros and logs
You check app armor
You check the debian release notes
You search for strange security features, breaking basic file system
functionality
...

You'll find nothing (you'll find something,
if you know the result of your search).

File access rights are a not corner case feature of some
special programm with security holes, it's a basic file
system feature that is now "broken".
fs.protected_regular=
To introduce that without a visibile mention
is giving your users the finger in my opinion."

----------------------------------------------------------------


The NewInBullseye document continues:

"The protection may be disabled temporarily by running sysctl
fs.protected_regular=0 and sysctl fs.protected_fifos=0 or permanently by
creating a file with a name ending in .conf in the /etc/sysctl.d
directory, containing these lines:

fs.protected_regular=0
fs.protected_fifos=0
"

Take a look at /usr/lib/sysctl.d/protect-links.conf . Devuan, presumably
following Debian, uses that file to override your sysctl.conf. Its
another systemd feature: "systemd-sysctl uses the common logic for
systemd-related config files: if you want to override
/usr/lib/sysctl.d/protect-links.conf, you must do so in a file named
/etc/sysctl.d/protect-links.conf.

You can then verify this will work by checking the output of
/lib/systemd/systemd-sysctl --cat-config"

Well, no, we can't verify that because we aren't running systemd.

Personally, I'm setting fs.protected_regular=0 to revert to the old,
well-understood behavior. I've kept the defaults on the other
fs.protectred_* items, which seem reasonable.

I'm not sure how to protect my systems from the tentacles of creeping
potterism, which now wants to override my sysctl settings.