Apparently everyone can. That's the bug, or at least a big part of it.
There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account.
>>There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account.
My mind has been blown. I can delete this .txt as the user "pikachu". I had no idea.
pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la
total 8
drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:48 .
drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 ..
-rw-r--r-- 1 root root 0 Jun 17 08:48 gogogadgetarms.txt
pikachu@POKEMONGYM ~/tmp3/pikachuFolder $
pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ rm gogogadgetarms.txt
rm: remove write-protected regular empty file ‘gogogadgetarms.txt’? y
pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la
total 8
drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:52 .
drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 ..
pikachu@POKEMONGYM ~/tmp3/pikachuFolder $
Well, the UNIX case is not a bug, it's by design. A directory is a list of files, so you remove a file by removing it from that list, the directory. The permissions of the file itself are for access/modifying of the contents of the file itself.
That's technically correct but it violates the principle of least surprise. Most users find the behaviour unexpected even though it's fairly easy to remember and real-world analogues abound (e.g. you can shred an envelope without reading the contents).
It's not clear to me that this is a common-enough situation to warrant changing anything so the best answer is probably to make sure documentation is easily found.
1. The user has write permission for the directory.
2. The user does not have write permission for the file.
3. The file has only one hard link.
4. The user deletes the file.
--that the last hard link should be moved to ~owner home directory, rather than deleted. Otherwise, I don't see a problem.
Again, I'm not sure this happens very often – most projects have tended to focus on avoiding cases where you have users crossing security boundaries like this. At the very least, setting the sticky bit seems to avoid a great deal of potential confusion.
I haven't thought about this in depth but here are the edge cases which come to mind on first thought with your proposal:
1. What happens if that file is on a different filesystem than the owner's home directory?
1a. What if the home directory is on a filesystem which doesn't have room?
1b. What happens if that would cause the user to exceed a size or inode quota?
2. How does this interact with e.g. lockd in an NFS environment?
3. How does it get a filename / how do we avoid security issues? For example, if I have write access to a directory I can rename the file to, say, .bashrc before I call unlink() so this would probably require generated some sort of reasonably informative name which can't collide ("deleted-by-<uid>-<hostname>-<inode>-<SHA-256>-<sequence>"?).
You could probably handle some of this by following the tradition of `lost+found` and moving it to a directory on the same filesystem which has the sticky bit set.
You put a bit more effort into this than I did. I only said the first thing that came to mind that would prevent a user without write permission from deleting the file, which is a near-equivalent to blindly overwriting the contents of a file with nothing.
There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account.