Where to report: root fails to edit other users file in sticky bit directory
Hi Debian team,
I'm sorry to contact you here, but I ran into an IMO extremely important
bug where I don't know which package is actually responsible.
Even the root user is not permitted to write to an existing file that is
owned by another user within a sticky bit directory:
-------
2020-12-04 14:16:58 root@micha:/tmp# whoami
root
2020-12-04 14:17:07 root@micha:/tmp# ls -dl
drwxrwxrwt 5 root root 100 Dec 4 14:17 .
2020-12-04 14:17:10 root@micha:/tmp# > testfile
2020-12-04 14:17:13 root@micha:/tmp# chown nobody testfile
2020-12-04 14:17:17 root@micha:/tmp# chmod 0777 testfile
2020-12-04 14:17:21 root@micha:/tmp# ls -l testfile
-rwxrwxrwx 1 nobody root 0 Dec 4 14:17 testfile
2020-12-04 14:17:23 root@micha:/tmp# > testfile
bash: testfile: Permission denied
2020-12-04 14:17:26 root@micha:/tmp# rm -v testfile
removed 'testfile'
2020-12-04 14:17:31 root@micha:/tmp# ls -l testfile
ls: cannot access 'testfile': No such file or directory
-------
- The sticky bid should only prevent removal of a file by other users,
not writing to it. root of course should always have permission to do both.
- This issue happens only on Debian Bullseye, independent from Linux
version and architecture (tested on x86_64 Debian with Linux 5.8 as well
as Raspberry Pi OS with Linux 5.4).
- It happens as well on at least tmpfs and ext4 file systems, so I
assume all file systems.
- Not only shell redirects are affected, but all ways to write the file.
I first observed it during a Python pip install as root user.
- It does not depend on either the shell or the way root was invoked.
bash, dash, sudo, direct root login all behave the same.
Please advice me who to forward this to or which package is
responsible/involved.
Best regards,
Micha
Reply to: