mv) is essentially an attribute-preserving copy followed by a deletion (
rm), as far as permissions are concerned.1 Unlinking or removing a file means removing its directory entry from its containing directory. You are writing to the directory, not the file itself, hence no write permissions are necessary on the file.
Most systems support the semantics of the sticky bit on directories (
chmod +t dir/), which when set only allows file owners to remove files within that directory. Setting the sticky bit on
cgi-bin/ would mean
moorc can no longer unlink files in
cgi-bin that belong to
1 In general, when the destination is in the same filesystem as the source, there is no physical copy. Instead, a new link is made to the file in the destination directory, but the same general concept still holds that the file itself does not change.
For more reading, look at this article explains how file and directory permissions (including the sticky bit) affect system calls.
I ran across an amusing analogy I really liked in a comment by @JorgWMittag on another question on this site.
It is identical to how an actual, "real-life" directory works, which is why it's called "directory", and not, for example, "folder", which would behave quite differently. If I want to delete someone from my phone directory, I don't go to her house and kill her, I simply take a pen and strike through her number. IOW: I need write access to the directory, and no access to her.
The analogy does break down a bit if you try to stretch it, because there's no effective way to describe the situation where the filesystem implementation automatically frees a file's disk blocks once the number of directory entries pointing to it drops to zero and all of its open handles are closed.