[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

Am 08.12.2020 um 16:55 schrieb tomas@tuxteam.de:
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

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

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 program.

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.

Best regards,


Reply to: