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 *remove* the file as a whole and add new files. <sup>1</sup> As a result, it *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.<sup>2</sup>

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

<sup>1</sup><sub>This 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.</sub>

<sup>2</sup> 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`, but overwrite its whole contents (`more text bla\n` in my case). I guess this explains why the inode number does not change.