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

Re: Where to report: root fails to edit other users file in sticky bit directory

Sorry for the late reply guys, I was not subscribed to the list, just got the address from the bug report instructions in case the related package could not be identified, and thought I get an answer directly to my mailbox xD: https://www.debian.org/Bugs/Reporting.en.html

Back to topic.

I totally forgot to make clear that it is an issue on Debian Bullseye only. On Buster this would have been recognised much earlier ;).

root@VM-Bullseye:/tmp# id
uid=0(root) gid=0(root) groups=0(root)
root@VM-Bullseye:/tmp# >> testfile
-bash: testfile: Permission denied
root@VM-Bullseye:/tmp# dash -c '>> testfile'
dash: 1: cannot create testfile: Permission denied


As said, the issue was first recognised during a Python module install, so in a totally different environment. My shell is bash as well, but I can reproduce the issue with any shell or any other language to write to a file in sticky bit directories.

root@VM-Bullseye:/tmp# id
uid=0(root) gid=0(root) groups=0(root)
root@VM-Bullseye:~# cd /tmp
root@VM-Bullseye:/tmp# df -T
Filesystem     Type     1K-blocks   Used Available Use% Mounted on
udev           devtmpfs   1016164      0   1016164   0% /dev
/dev/sda1      ext4       8189368 584548   7169108   8% /
tmpfs          tmpfs      1018568      0   1018568   0% /dev/shm
tmpfs          tmpfs       407428   5504    401924   2% /run
tmpfs          tmpfs         5120      0      5120   0% /run/lock
tmpfs          tmpfs         4096      0      4096   0% /sys/fs/cgroup
tmpfs          tmpfs      1018880  37432    981448   4% /tmp
tmpfs          tmpfs        51200      8     51192   1% /var/log
root@VM-Bullseye:/tmp# cd /root
root@VM-Bullseye:~# mkdir testdir
root@VM-Bullseye:~# chmod 1777 testdir
root@VM-Bullseye:~# > testdir/testfile
root@VM-Bullseye:~# chown www-data testdir/testfile
root@VM-Bullseye:~# > testdir/testfile
-bash: testdir/testfile: Permission denied
The issue is not related to the file system and not related to the kernel version. As said I tested in on RPi with their current stable Linux 5.4 (now with a second recent update) and on Bullseye with now as well two kernel versions. But to be sure, I'll downgrade the kernel to a previous major version, probably from Buster backports, just to be sure.

This is a bug clearly, I'm just not sure, if kernel and file system and shell/environment does not play a role, which part of the OS does, i.e. is sitting between userland programs and kernel/fs driver to verify UNIX permissions.

Best regards,


Reply to: