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.
