Witness the following:

sh-3.2$ mkdir testcase
sh-3.2$ cd testcase
sh-3.2$ sudo touch temp
sh-3.2$ ls -al
total 0
drwxr-xr-x   3 glen  staff  102 19 Dec 12:38 .
drwxr-xr-x  12 glen  staff  408 19 Dec 12:38 ..
-rw-r--r--   1 root  staff    0 19 Dec 12:38 temp

sh-3.2$ echo nope > temp
sh: temp: Permission denied

sh-3.2$ vim temp
# inside vim
# press [ESC]
# vim exits

sh-3.2$ ls -al
total 8
drwxr-xr-x   3 glen  staff  102 19 Dec 12:38 .
drwxr-xr-x  12 glen  staff  408 19 Dec 12:38 ..
-rw-r--r--   1 glen  staff    7 19 Dec 12:38 temp

Somehow vim has taken this root-owned file, and changed it into a user owned file!

This only seems to work if the user owns the directory - but it still feels like it shouldn't be possible. Can anyone explain how this is done?

3 Answers 3


You, glen, are the owner of the directory (see the . file in your listing). A directory is just a list of files and you have the permission to alter this list (e.g. add files, remove files, change ownerships to make it yours again, etc.). You may not be able to alter the contents of the file directly, but you can read and unlink (remove) the file as a whole and add new files subsequently.1 Only witnessing the before and after, this may look like the file has been altered.

Vim uses swap files and moves files around under water, so that explains why it seems to write to the same file as you do in your shell, but it's not the same thing.2

So, what Vim does, comes down to this:

cat temp > .temp.swp          # copy file by contents into a new glen-owned file
echo nope >> .temp.swp        # or other command to alter the new file
rm temp && mv .temp.swp temp  # move temporary swap file back

1This is an important difference in file permission handling between Windows and Unices. In Windows, one is usually not able to remove files you don't have write permission for.

2 update: as noted in the comments, Vim does not actually do it this way for changing the ownership, as the inode number on the temp file does not change (comaring ls -li before and after). Using strace we can see exactly what vim does. The interesting part is here:

open("temp", O_WRONLY|O_CREAT|O_TRUNC, 0664) = -1 EACCES (Permission denied)
unlink("temp")                               = 0
open("temp", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 4
write(4, "more text bla\n", 14)              = 14
close(4)                                     = 0
chmod("temp", 0664)                          = 0

This shows that it only unlinks, but does not close the file descriptor to temp. It rather just overwrites its whole contents (more text bla\n in my case). I guess this explains why the inode number does not change.

  • 3
    FWIW you can verify this is happening by running ls -il before and after ... if temp's inode number changed, you know it's a different file with the same name.
    – Useless
    Commented Dec 19, 2012 at 14:12
  • 3
    One could add that rm does not actually remove the file, but just removes a link to the file, and the file doesn't get deleted before the number of links decreases to 0. rm just removes the entry to the file in the directory. If root has another link (hard link) to the file in another directory, the user cannot remove the file.
    – gerrit
    Commented Dec 19, 2012 at 14:21
  • 1
    @Useless I tried, and the number didn't change though the owner and the timestamp changed!
    – amyassin
    Commented Dec 19, 2012 at 18:45
  • 1
    @amyassin You're right! I've updated my answer with an strace excerpt explaining it.
    – gertvdijk
    Commented Dec 19, 2012 at 19:09
  • 2
    As an aside to your note about Windows vs. Unix permissions, if you want Windows-like behavior in Unix, you can create a directory owned by root (or another user who should have universal remove/rename/etc permissions) and set the sticky bit on the directory. Then users will only be able to delete their own files. Commented Dec 19, 2012 at 19:39


-rw-r--r-- 1 root staff 0 19 Dec 12:38 temp


-rw-r--r-- 1 glen staff 7 19 Dec 12:38 temp

The vim does not break through the permission barrier. Just have a look at the file information listed carefully then you could find out that vim actually deleted the original file (because you have the permission to remove the file though you can't change its content) then created a new file of you own (see the owner is no longer 'root').

And while you're editing the original file in vim, it warns that you're changing a read-only file. So when you type the command :wq!(force the operation), what can vim only do is to delete the existing file and create a new file which has the identical name.

Hope that helps.


Use the -i option of ls to see the inode number, which is a unique identifier (within the filesystem) of a file or other object.

You will see that the file was replaced with a different object: the inode number will likely change.

Seeing the same inode number is not proof of anything: an inode number can be recycled. If we remove the last link to a file, and then create a new file, we might get one with the same inode number. But that cannot happen if the old file is removed after the new one is created. E.g. mv file file.tmp; touch file; rm file.tmp. I suspect vim actually does something analogous to this echo new_content > tmpfile; mv tmpfile file. The mv operation will translate to a rename system call, so the assignment of inode numbers depends on how the filesystem implements a rename which unlinks a destination.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .