Bug 1248203 - Write permissions to files not intended to write
Write permissions to files not intended to write
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Václav Pavlín
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-07-29 16:34 EDT by ladieda
Modified: 2015-08-03 10:52 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-08-03 10:52:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
short example of the flow (1.67 KB, text/plain)
2015-07-29 16:34 EDT, ladieda
no flags Details

  None (edit)
Description ladieda 2015-07-29 16:34:48 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

How reproducible:

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.

Actual results:
file is modified even if there was no access granted for the local user

Expected results:
access denied on the file for editing/saving

Additional info:
SELinux enabled (targeted - enforced)
Comment 1 Devin Henderson 2015-07-29 16:39:05 EDT
Can confirm this. Amazingly, I am able to overwrite the file with :wq! despite not having write access to it.
Comment 2 Devin Henderson 2015-07-29 19:34:15 EDT
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?
Comment 3 Devin Henderson 2015-07-29 19:41:24 EDT
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.
Comment 4 Devin Henderson 2015-07-29 19:48:52 EDT
"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."
Comment 5 ladieda 2015-07-30 03:08:56 EDT
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?
Comment 6 ladieda 2015-07-30 03:59:51 EDT
Example (another system same logic goes):

[alice@host-6-1 ~]$ ls -l
total 0
drwxr-x---. 2 root alice 34 Jul 30 08:26 test
[alice@host-6-1 ~]$ cd test
[alice@host-6-1 test]$ ls -l
total 8
-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
[alice@host-6-1 test]$

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?
Comment 7 ladieda 2015-08-03 10:52:25 EDT
ok, found out you can add the root to the group to solve this. 
Anyway, this seems by design, so no bug.

Note You need to log in before you can comment on or make changes to this bug.