Bug 150976 - takes ownership from anybody's file
Summary: takes ownership from anybody's file
Alias: None
Product: Fedora
Classification: Fedora
Component: dos2unix   
(Show other bugs)
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: Ben Levenson
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-13 08:10 UTC by Dhruv Ahuja
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-13 21:21:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Dhruv Ahuja 2005-03-13 08:10:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

Description of problem:
If a user has write permissions to a directory and read permissions to a file in the same directory (a file which belongs to a different user/group) - the dos2unix command can make the working user the owner of that file.

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

How reproducible:

Steps to Reproduce:
1. login a root and go to a user's home directory (say user is jack).
2. create a file abcd.
3. make sure the file has read permissions for jack.
3. logout and then login as jack.
4. see the directory listing and confirm that 'abcd' is owned by root.
5. dos2unix abcd

Actual Results:  the owner of the file is jack now

Expected Results:  the command should've failed to run due to a permissions error, or prompted for a different filename for output.

Additional info:

this scenario requires that the working directory had write permissions for the user jack. and that the file had read permissions.

Comment 1 keith adamson 2005-03-13 18:56:18 UTC
NOTABUG.  This is true for a lot of Unix utilities that do in-place
file operations.  For example, sed has the same behavior  Even though
"jack" doesn't own "abcd" he can remove it since he has write
permissions to his $HOME directory.


rm abcd
echo "now abcd is mine" > abcd

Comment 2 Mike A. Harris 2005-03-13 21:21:15 UTC
Correct, this is NOTABUG.  As indicated in comment #1, this is
standard correct UNIX behaviour.  The right to remove a file
is given by the permissions of the directory, not the permissions
of the file.

[root@laser mharris]# cd ~mharris
[root@laser mharris]# pwd
[root@laser mharris]# echo "root file" > root-owns-this.txt
[root@laser mharris]# ls -ail root-owns-this.txt
327720 -rw-r--r--  1 root root 10 Mar 13 16:12 root-owns-this.txt
[root@laser mharris]# chmod 600 root-owns-this.txt
[root@laser mharris]# ls -ail root-owns-this.txt
327720 -rw-------  1 root root 10 Mar 13 16:12 root-owns-this.txt

So above you see I have created a file in mharris' home directory
as the root user.  The file is owned by root:root and has no
read/write/execute permissions for mharris.

Now mharris removes the file:

pts/6 mharris@laser:~$ ls -ail root-owns-this.txt
327720 -rw-r--r--  1 root root 10 Mar 13 16:12 root-owns-this.txt
pts/6 mharris@laser:~$ rm root-owns-this.txt
rm: remove write-protected regular file `root-owns-this.txt'? y
removed `root-owns-this.txt'
pts/6 mharris@laser:~$ ls -ail root-owns-this.txt
/bin/ls: root-owns-this.txt: No such file or directory

As you can see, mharris did not own the file, nor did he have
permission to read or write the file, nor execute it.  However,
mharris owns his home directory, and has rwx permissions on his
home directory.  The directory permissions grant mharris the
right to remove files from the directory he owns, and so while
he can not read/write/execute the file, he definitely is granted
permission to delete it by the filesystem.

In the case of dos2unix/unix2dos, the original file is owned
by root and readable, so the utility reads it fine, then writes
out a *new* file, which takes ownership of the invoking user
with permissions defaulted to that given by the current umask.
Then after the new file is created, the original root owned
file is removed.

If this seems confusing, the chmod manpage and GNU info
documentation on the standard UNIX utilities may be useful.
Additionally, any general purpose introductory UNIX/Linux
book should have a chapter on how filesystem permissions work.

On a side note...  if root wanted to create a file in a user's
directory that was truly not removable by the user, he could
use "chattr +i" to flag the file as immutable, or potentially
set ACLs on the file if the filesystem the file resides on
implements ACL functionality.

Hope this helps.

Comment 3 Mike A. Harris 2005-03-13 21:26:05 UTC
Minor correction - some utilities read a file and write out a new
file, in which case the inode number will change even though the
file name remains the same.  In the case of these utils, the file
is changed in place reusing the same inode.  Same difference however.

Just wanted to clarify that in case someone decided to explore
this more, because it differs slightly from what I said above.

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