[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
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,


Reply to: