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: Always 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.
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. Example: rm abcd echo "now abcd is mine" > abcd
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 /home/mharris [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.
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.