Bug 56410 - User could modify files of user root (rw-r--r--)
Summary: User could modify files of user root (rw-r--r--)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-11-16 22:03 UTC by Need Real Name
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-11-16 22:18:59 UTC
Embargoed:


Attachments (Terms of Use)
Example to reproduce (810 bytes, patch)
2001-11-16 22:04 UTC, Need Real Name
no flags Details | Diff

Description Need Real Name 2001-11-16 22:03:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010923

Description of problem:
If root create files in a home directory of a user. The user could
overwrite the file and the owner root is replaced with the id of the user.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. login as root
2. create a "test" user
3. create a file ~test/test
4. chown root:root ~test/test
5. chmod 0644 ~test/test
6. logoff
7. login with user "test"
8. check file attribute of ~test/test
9. call vi ~test/test
10. Modify the file (Ignore error messages)
11. Save the file with vi command ":w!"
    PLEASE, DON'T FORGET "!". ! will produce the problem.
12. Leave vi with ":q"

	

Actual Results:  ~test/test has owner test and group users.

Expected Results:  A file (~test/test) with 0644 Attribute of user root
should never be modified by another user.


Additional info:

The error is reproducable in the complete user directory tree.
Reproduceble also on other Distributions and other hardware plattforms.

A shell-script in a attachment will help you, to reproduce the problem.

Comment 1 Need Real Name 2001-11-16 22:04:27 UTC
Created attachment 37802 [details]
Example to reproduce

Comment 2 Arjan van de Ven 2001-11-16 22:10:52 UTC
The user can't DIRECTLY modifiy the file
However:
Since he owns the directory, he can rename the file
Since he owns the directory, he can then make a new file with the same filename
as the now renamed file had
Since he owns this new file and can read the old file, he can copy the old
contents in
Since he owns the directory, he can either remove the old file or keep it as backup
....
....
and this is what vi does ;(

Comment 3 Pete Zaitcev 2001-11-16 22:18:53 UTC
Here is the interesting part of the strace -
the documentary evidence to what Arjan mentioned.


open("xxx", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission
denied)
getuid32()                              = 531
unlink("xxx")                           = 0
open("xxx", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
write(4, " ## Notes\necho -ne \"\\033]0;Work\\"..., 8192) = 8192
write(4, "/monte-200107261702.tar.bz2\n\n ##"..., 8192) = 8192
write(4, " was \n           going to work o"..., 221) = 221
close(4)                                = 0
chmod("xxx", 0644)                      = 0
write(1, " 447L, 16605C written", 21)   = 21


Comment 4 Arjan van de Ven 2001-11-16 22:21:32 UTC
If you want files that the owner of the directory REALLY cannot modify,
you can mark them "immutable" with "chattr +i <filenam>"

I'm closing this as "NOTABUG", however if you don't agree with that please
reopen the bug.


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