Might be a bug or I might be dumb 50/50 chance.
I don’t think I did anything wrong installing EOS (I’ve used it for almost a year now), but the background here is that I was using a Kiwix appimage run as a normal user that can somehow delete a root-owned file but not a root-owned file in a root-owned directory. This normal user is in the ‘wheel’ group (can use sudo), but the appimage was NOT run with sudo.
More details are here with a video showing what happened:
What are the permissions on the directory the file was contained within?
If you have write permissions to the directory, you can delete files within it.
It was 755 user:user on the directory, but the file was 444 root:root.
If you can write to the directory, you can delete the file.
The file is an entry in the directory.
Test it out:
mkdir ~/test
touch ~/test/testfile
chmod o-w ~/test/testfile
chown root:root ~/test/testfile
rm ~/test/testfile
Whether you do this via terminal or put into a bash script, it shows the stderr requiring user input:
rm: remove write-protected regular empty file '/home/matt/test/testfile'?
Shouldn’t the kiwix program also error out?
No, you have the rights to do it. In this case, rm is just asking if it should do it.
If you used rm -f it would work without confirmation.
I guess I misunderstood how the permissions worked, I assumed that if a file wasn’t owned by you or if you weren’t in that group’s permission, you couldn’t delete it, especially if the “other” group didn’t have w (modify) permissions.
That’s normally true, if the file is in a directory that you don’t own. But if you own the directory, you can delete everything in it. If you think about it, that actually makes sense.