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:
opened 05:55PM - 28 Aug 20 UTC
closed 02:22PM - 30 Aug 20 UTC
bug
question
So, I downloaded some content and tested Kiwix Reader on my EndeavourOS (arch-ba… sed) Linux system. In your Kiwix library, it lists all of your .zim files and when you right-click, you can select "Open" or "Delete".
There is no "Remove from Library button", only a "Delete" button, and when you select delete, it completely deletes it from your hard drive. "Okay", I hear you all say, "What's the actual issue"?
The issue (other than not having a "remove from library button") is that kiwix (when run as a normal user) somehow is using superuser (aka root, aka administrator) privileges when it deletes files. I set up a test where I changed the privileges of the .zim file and kiwix still deleted the file! Privilege escalation is a major security flaw (especially if it ever gets exploited to delete things that are not .zim files)!
These were my steps:
```
sudo chown root:root file.zim
sudo chmod 444 file.zim
```
Kiwix still deleted the file, it should have errored out but didn't.
---
I was able to figure out how to get it to work (where "Delete" cannot delete the file but does remove it from the library). Refer to these steps:
```
sudo chown -R root:root folder_containing_zim_files
sudo chmod -R 555 folder_containing_zim_files
```
---
The whole reason for these tests was because I wanted to test how Kiwix handled deletion prior to running a Kiwix server in my house (waiting on Amazon parts). Is there a way to fix this within Kiwix? Does the Kiwix Server act in the same manner? Thanks.
Original Reddit Post: https://www.reddit.com/r/Kiwix/comments/iibqtp/major_bug_delete_button_in_kiwix_reader_linux/
dalto
August 29, 2020, 5:01pm
2
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.
dalto
August 29, 2020, 5:22pm
4
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
dalto:
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?
dalto
August 29, 2020, 5:39pm
6
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.
2 Likes
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.
1 Like
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.
5 Likes