No permissions to write to other users 777 file in sticky bit dir, even as root
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
Reply to: