Hey guys,

since the (Bullseye) testing list seems to fit better, let me summarize
the issue that I reported to user list initially: https://lists.debian.org/debian-user/2020/12/msg00122.html

- Inside a directory with sticky bit set, even the root user is not able/permitted to write to files that are not owned by him, regardless
of file and directory modes (aside of the directories sticky bit).

- root can remove the file (which is what the sticky bit should prevent
for non-root users) and can create own files of course, it can even
change owner/modes of the file, but it cannot write to it.

- It doesn't matter how the file write is done, i.e. regardless of shell
or invoking program (like a Python or PHP script), it fails all with permissions denied.

- The issue happens on all systems with current Debian Bullseye userland installed, regardless of kernel or hardware, tested with arm64 kernel
from Buster and Buster backports on x86_64 VM and notebook and current
stable Linux 5.4 kernel from Raspberry Pi Foundation on a Raspberry Pi 2
that is using the official Debian repository for everything no kernel/bootloader/firmware related.

- The issue happens on tmpfs and ext4 file systems, so assumed to happen
on all file system types that support UNIX permission modes.

- It was tested to move from systemd to SysV to be able to remove
libapparmor1, even purging udev, but the issue persists. The systems
were otherwise very minimal, comparable to fresh mini.iso install
without additional software selected.

Steps to reproduce:
1. Boot into a Debian Bullseye root user shell.
2. mkdir -m 1777 testdir
3. > testdir/testfile
4. chown nobody testdir/testfile
5. >> testdir/testfile

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Okay, the reason has been found:

- https://lists.debian.org/debian-user/2020/12/msg00305.html

- https://patchwork.kernel.org/project/kernel-hardening/patch/20180416175918.GA13494@beast/

Since Debian Bullseye sysctl fs.protected_regular defaults to "2", which
denies every attempt of a O_CREAT write to a file, that is not owned by oneself, inside a world-writeable sticky bit directory.

The problem I have with this:

- It practically breaks writeable sharing files through /tmp between
multiple users/processes, since O_CREAT is involved in many regular file
write methods, like shell redirects, but this is expected for the
security purpose.

- It is not documented anywhere related to /tmp or the sticky bit, so at
least on my end it was totally unexpected, especially when something
does not work anymore that one was used to until Debian Buster.

- root user is currently included, while it is permitted to remove any
file in a sticky bit directory, which is the actual documented intention
of the sticky bit. So IMO root user should be taken out of this
restrictions. But I'm not sure if this is even possible when this is a kernel-level feature?

So not sure how to handle best:

- Add info about those additional restrictions to the chmod man page: https://manpages.debian.org/testing/coreutils/chmod.1.en.html#RESTRICTED_DELETION_FLAG_OR_STICKY_BIT

- Likely there are many other docs around modes where this info is
missing. Here I did find it: https://manpages.debian.org/testing/manpages/proc.5.en.html#Files_and_directories

- Revert fs.protected_regular to default "0" to not break what
previously worked without a very clear documentation and changelog,
probably extended error messages about that, if even possible at such a
level? That is actually what I would vote for since all software I know
places sensitive files into restricted sub directories of /tmp or /run
and/or use systemd's PrivateTmp anyway. So if someone really needs to
have this extra bit of security, it can always be enabled manually, but
as a default that breaks things in a hard to debug and unexpected way is
not a good default, IMO.

Best regards and stay healthy,

Micha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)