On Mon, May 29, 2023 at 11:45:33AM -0700, Richard Doyle via Dng wrote:
> 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.

cat /proc/sys/fs/protected_fifos

shows the status of the fs.protected_regular kernel parameter.

> 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 would hope that this change to default kernel parameters
is documented in the upgrade guide.

I didn't notice this change breaking my rsync backups using
Time Machine style hardlinks.

Whether or not initiated by the systemd developers, it was
okayed by bullseye developers. I don't think we can blame
them for wanting more secure default settings.

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

Whether in /etc/sysctl.d/conf/* or /usr/lib/sysctl.d/99-protect-links,
seems like you can specify what you want.

It's a reality that debian will change over time. How much
breakage is acceptable for which purposes is a contentious
subject.

have fun (and upgrade with eyes wide open)

--
Joel Roth