Bug 1248203
| Summary: | Write permissions to files not intended to write | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | ladieda <alexmeys> | ||||
| Component: | distribution | Assignee: | Václav Pavlín <vpavlin> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 22 | CC: | artxch, dennis, devin, notting, sheldon.corey | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-08-03 14:52:25 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 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? ok, found out you can add the root to the group to solve this. Anyway, this seems by design, so no bug. |
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: 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)