Re: Where to report: root fails to edit other users file in sticky bit directory
Am 08.12.2020 um 16:55 schrieb email@example.com:
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
Oh, I see. Strange error message though -- I'd expect dash to
try to open the file in append mode, not to `create' it.
Thanks for reporting back, cheers
I was also wondering about that, but dash prints this message regardless
if the file exists already or not, if permissions are not there. Note
that creating a new file works fine, removing a file as well, only
writing to an existing file fails, regardless of shell or originating
I now also tested to switch from systemd to SysV init, which allowed to
remove libapparmor1. I even purged udev (which breaks network) to get
rid of any systemd package, but the issue remains. Strangely the three
AppArmor init messages remain:
[ 1.051669] AppArmor: AppArmor initialized
[ 1.328558] AppArmor: AppArmor Filesystem Enabled
[ 1.782311] AppArmor: AppArmor sha1 policy hashing enabled
I think this is fixed part of grub or the kernel then. However, on RPi,
with different kernel and different bootloader, those messages are not
present, but the issue is.
So I'm still completely out of ideas.
Btw, if someone knows an "official" Debian mailing list with
maintainers/developers, where this can be reported, that might be
helpful. If it is clearly related to a certain package, things are easy
to address correctly, but in this case I have no clue.
I think best to debug is if someone with deeper insights is replicating
this on an own system. But of course I'll go on trying/testing ideas,
that come to my mind of thrown in here.