mv file without write permission to the source file

Question

I just realised that I can move a file that I do not own and don't have write permissions on. I have write permissions to the directory, so I am guessing that is why I could move it, but in this instance, is there anyway of protecting the source file?

The permissions for the file are as follows;

cgi-bin> ls -al 

drwxrwxrwx   3 voyager  endeavor     512 Feb  1 10:45 .
drwxrwxrwx   6 voyager  endeavor     512 Feb  1 09:38 ..
-rwxr-xr-x   1 voyager  endeavor   22374 Feb  1 10:45 webvoyage_link.cgi

cgi-bin> whoami
moorc

cgi-bin> groups
lrsn endeavor

cgi-bin> rm webvoyage_link.cgi
rm: webvoyage_link.cgi: override protection 755 (yes/no)? yes

This last one is a big surprise to me to. How can I delete a file that I don't have access to. There is obviously something I'm missing.

Solution

Move (mv) is essentially an attribute-preserving copy followed by a deletion (rm), as far as permissions are concerned.¹ 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 voyager.

^{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. Postscript

I ran across an amusing analogy I really liked in a comment by @JorgWMittag on another question on this site.

Excerpt

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.

Comments

[Maximiliano Padulo]

Excellent. Nicely explained and I'm no longer confused. I had heard about sticky bits before, but never really knew what they were used for.

[Michael Dillon]

Actually, sticky bits were used to indicate binaries that should not be cleared from memory after execution finished because they would likely be used frequently. That's how it was in 1976. Somewhere along the line kernels evolved and this was obsolete, but there was this bit hanging around with nothing to do, and the chmod command knew how to set it already.

[psusi]

@MichaelDillon, even in the late 70s the sticky bit already behaved this way on directories. It was usually set on /tmp to prevent users from deleting each other's temp files.

[jw013]

@MichaelDillon If you look at the edit history, I specifically added "on directories" after sticky bit before your comment just to avoid any confusion between different meanings of the sticky bit when applied to executables or directories. I generally like to keep answers short and to the point so it was not my intention to explain any historical background, but your comment does add to the discussion, so +1 from me.

[Kyle Jones]

@psusi There's no way the sticky bit did anything on directories in the 1970's. I remember the feature appearing in 4.something BSD in the mid-or-late 1980's. The text file semantics did predate the BSDs.

[psusi]

@KyleJones, perhaps the directory semantics did come later, but my point was that they both overlapped for some time. In particular, I'm pretty sure that AT&T sysVr4 had both the binary text segment and shared directory semantics, and IIRC, so did early versions of Linux.

[Gilles 'SO- stop being evil']

My earlier comment was incorrect. Moving within a filesystem is the same as copying-then-deleting as far as permissions on the directories are concerned, but moving does not require any permission on the file itself, unlike copying.