Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I created a file, did chmod 000 to it and then changed the owner and group to root:root. I was still able to delete the file as the original creator of it (not root).

Who has permissions to delete a file?

share|improve this question
5  
To clarify the answers a bit, you aren't "deleting" the file you are unlinking it. The file system knows about the file by a link, which are a part of the parent directory. So the file permission on the file do not apply because technically it's still there (recovering an unlinked file is next to impossible, but sometimes you can find it in the disk's data). It's just no longer pointed to by the directory, hence in removing the link you're actually editing the contents of the directory, so it's permissions that apply. –  Chris S Jan 7 '12 at 4:16

2 Answers 2

up vote 17 down vote accepted

The permissions of the containing directory determine the ability to rename and delete files.

Specifically, to delete/rename a file, a user needs to have write and execute (i.e. traversal) permissions on the containing directory, and the file in question must not be immutable. (Under these circumstances, a non-privileged user can even delete files owned by root.)

Restricted Deletion:

It is possible to restrict deletion of files to only the owner of the files (and privileged users), by setting the 'sticky bit' (also known as the 'restricted deletion flag') on the containing directory using: chmod +t directory. A directory with the sticky bit set, displays a 't' in the last position (e.g. drwxr-xr-t) - this can also be set in 'octal' form by prefixing the 3 digit octal code with a '1' (e.g. chmod 1755 directory). (Linux ignores the sticky bit on files - although some other operating systems do assign meaning to it.)

Read Permissions:

You should note that the read permission on the containing directory is not required. Without it, you will still be able to delete the file, if you know its name, although you will not be able to 'read' the contents of the directory (e.g. without read permissions you cannot run ls).

Immutable Files:

As a side point, by making a file immutable (i.e. chattr +i) neither the owner nor other users (including privileged users) will be able to delete (or rename, link to, or modify) the file, even if they have write permissions on the directory (only the superuser can remove this).

share|improve this answer
1  
An excellent answer except that although chmod +t [-v] dir does what you suggest, chmod +t [-v] file doesn't. I've just tested it, and although I can't paste the results into a comment, they can be seen at teaparty.net/data/serverfault-347589.html and seem pretty definitive. –  MadHatter Jan 7 '12 at 9:34
    
You are absolutely right - the sticky bit is ignored completely by Linux operating systems on files, but is the 'restricted deletion flag' when applied to folders. Thank you for pointing that out, I will modify the answer. –  cyberx86 Jan 7 '12 at 9:52
    
Glad to help! And it's not just Linux, I tested it on Solaris 8 and observed the same behaviour. –  MadHatter Jan 7 '12 at 14:19
    
@MadHatter: as far as I know (or can find documentation to support), no operating system interprets the sticky bit on a file as restricted deletion. Many simply ignore the sticky bit (e.g. Linux), while others have a different meaning for it (e.g. the way the file is stored in swap). (Not an 'authoritative source' but, Wikipedia's - Sticky bit has a nice summary of the meaning on different operating systems.) –  cyberx86 Jan 8 '12 at 1:33
    
cyberx86: that's rather what I thought, too; but all credit to you for some references! –  MadHatter Jan 8 '12 at 8:18

The owner of the folder where the file resides will, if they have write permissions on the folder, be able to delete the file even if it's mask is 000 or the file is owned by another user. If you really want to create a file that no one can touch/delete you should look into the command chattr and its immutable flag.

From the documentation:

A file with the i attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

share|improve this answer

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.