Can you delete a file you have no write permission on?
Short answer
Yes, it can be possible. Removing a file (unlink) edits the parent directory, so Linux checks write (and search) permission on the directory, not on the file. A read-only file in a directory you can write to can be deleted. On shared directories like /tmp the sticky bit changes this: only the file's owner, the directory's owner, or a privileged process may delete or rename entries.
Many candidates answer "no" on instinct: if I can't write to a file, I can't delete it. On Linux that instinct is wrong, and the reason is a useful mental model of how filesystems work.
A file name is a directory entry
Deleting a file is the unlink(2) system call, which removes a name from a directory. So the permission that matters is on the directory. The man page lists, as a failure case, that "write access to the directory containing pathname is not allowed" for the process. The file's own mode bits (including read-only) are not what gates the deletion.
The sticky bit narrows this on shared directories
Directories such as /tmp are world-writable, so without a guard anyone could delete anyone else's files. The sticky bit (S_ISVTX) fixes that: per inode(7), a file in such a directory can be renamed or deleted only by the owner of the file, by the owner of the directory, or by a privileged process. You see it as a trailing t in ls -ld /tmp (drwxrwxrwt).
Why a security person cares
- A writable directory containing a root-owned script or config lets a low-privileged user replace it (delete, then create their own), even when they cannot edit the original. This shows up in privilege-escalation reviews.
- Hardening checklists therefore flag world-writable directories that lack the sticky bit.
Why the distractors are tempting
"Need write on the file" is the intuitive but wrong model. "Only root can delete" ignores ordinary users deleting their own files. "Ownership alone" mixes up the sticky-bit rule with the general rule.
What interviewers want
"Deletion is a directory operation, so directory write permission decides it, and the sticky bit restricts it on shared dirs." Mention a privesc example for extra credit.
Likely follow-ups
- What does the sticky bit do on /tmp, and how do you spot it in ls -l?
- How does this affect an attacker who can write to a directory containing a root-owned script?
- Which permission on a directory is needed to list names versus to open files inside it?