Red Hat Bugzilla – Bug 1248203
Write permissions to files not intended to write
Last modified: 2015-08-03 10:52:25 EDT
Created attachment 1057415 [details]
short example of the flow
Description of problem:
Version-Release number of selected component (if applicable):
Fedora 22 - 4.0.8-300.fc22.x86_64
Steps to Reproduce:
1. create test folder in user home directory (non root)
2. create test file in this folder as root
3. strip all rights (chmod -r filename)
4. check owner:group (root:root)
5. login as local user
5b. cat the file => permission denied
6. Go to file and edit with vi
7. save with :wq => it will complain about read only
8. save with :wq! => it will save
9. login as root see the changes made by a non root user.
file is modified even if there was no access granted for the local user
access denied on the file for editing/saving
SELinux enabled (targeted - enforced)
Can confirm this. Amazingly, I am able to overwrite the file with :wq! despite not having write access to it.
FWIW, I was able to reproduce this on Debian and Ubuntu as well. Can someone explain the logic behind this behavior? Is it really as nasty of a bug as it appears to be?
As nirik pointed out, this is normal behavior. The regular user is allowed to overwrite the file based on the permissions of the folder it is in.
"The write permission grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory. This includes creating files, deleting files, and renaming files."
This seems to me as odd behaviour? Let's say the root was a manager who wanted to add a private note in that folder. One has to remove permissions from the folder above just to edit 1 specific file and edit all the file permissions of the other files accordingly?
Example (another system same logic goes):
[alice@host-6-1 ~]$ ls -l
drwxr-x---. 2 root alice 34 Jul 30 08:26 test
[alice@host-6-1 ~]$ cd test
[alice@host-6-1 test]$ ls -l
-rw-rw-r--. 1 alice alice 21 Jul 30 08:25 aliceuser
--w-------. 1 root alice 10 Jul 30 08:36 tryme
[alice@host-6-1 test]$ touch icannotcreate.txt
touch: cannot touch Ç icannotcreate.txt Ç : Permission denied
so now alice cannot edit the 'tryme' file. However she cannot create files in this folder 'test' as there are no permissions set. she can still edit the 'aliceuser' file as permissions are set correct.
Now imagine 1000's of files in this directory of alice and just one note of the "manager" user?
ok, found out you can add the root to the group to solve this.
Anyway, this seems by design, so no bug.