Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question

1 Answer 1

up vote 11 down vote accepted

Move (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 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.

share|improve this answer
    
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. –  Mr Moose Feb 1 '12 at 5:35
3  
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. –  Michael Dillon Feb 1 '12 at 7:05
    
@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. –  psusi Feb 1 '12 at 15:23
    
@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. –  jw013 Feb 1 '12 at 20:53
1  
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. –  Gilles Aug 12 at 8:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.