Re: Where to report: root fails to edit other users file in sticky bit directory
On Fri, Dec 04, 2020 at 02:40:02PM +0100, MichaIng wrote:
> 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
"id" is a better command for determining your current privileges.
> 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
OK, the fact that chown works seems to indicate you are in fact root.
> 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
I would check the fstype and mount options on this file system.
Maybe it's not a regular old ext4-on-a-real-disk file system.
> - 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).
Ah, testing. Interesting test.
> - It happens as well on at least tmpfs and ext4 file systems, so I assume
> all file systems.
Does it also happen if you reboot back into the stable kernel? That
would at least tell you that it's the kernel (file system drivers?)
that have changed.
Reply to: