I recently got tested on an important piece of Linux file permissions trivia and must admit I fumbled the answer a bit.
My main reasons for not instantly getting the question right probably stems from my own personal mantra, “DO NOT 0777 ALL THE THINGS!”. I like to think that I put some thought into file and directory permissions rather than applying the same permissions to user, group and others. It is something that I have (on occasion) bullied a lot of developers about during my dictatorship employment as a (junior) Linux SysAdmin.
Let’s stop chmod 0777!
Now, the main reasons why I have been quite cruel about a persons choice of file permissions has been for the following reasons:
- Not everybody needs permissions to read/write the file or directory.
- It’s often unwise to be able to let someone else execute your code if they don’t know what it does.
- Files that are executable (that don’t need to be) can lead to the file being hijacked for malicious code to run.
However these reasons focus primarily on file permissions and only lightly touches on the implications for directories.
Directories of doom!
In this example I was asked to explain what would be the result of the following:
[ manningx@example:~/testdir ] $ ls -lah
total 8.0K
drwxrwxrwx 2 root root 4.0K Jan 8 15:18 ./
drwxr-xr-x 16 manningx manningx 4.0K Jan 8 15:17 ../
-rw------- 1 root root 0 Jan 8 15:18 filetodelete
[ manningx@example:~/testdir ] $ rm filetodelete
Feeling quite confident, I said: “The file filetodelete will fail to delete.”
This isn’t a bad first assumption, filetodelete is only read-writable for the root user, there are no permissions for group or others… surely it should fail if my user, manningx, tries to delete it.
Wrong.
I didn’t fully take in all the information and forgot one key piece of information. The result was the following:
[ manningx@example:~/testdir ] $ ls -lah
total 8.0K
drwxrwxrwx 2 root root 4.0K Jan 8 15:18 ./
drwxr-xr-x 16 manningx manningx 4.0K Jan 8 15:17 ../
-rw------- 1 root root 0 Jan 8 15:18 filetodelete
[ manningx@example:~/testdir ] $ rm filetodelete
rm: remove write-protected regular empty file ‘filetodelete’? y
[ manningx@example:~/testdir ] $ ls -lah
total 8.0K
drwxrwxrwx 2 root root 4.0K Jan 8 15:37 ./
drwxr-xr-x 16 manningx manningx 4.0K Jan 8 15:17 ../
Oh dear. The file has been removed! How did this happen?!
This relates to the one key piece of information I missed and did not fully comprehend. ~/testdir is owned by root, but has read-write-executable permissions for everyone! This directory has been chmod’d 0777!
The one rule to remember here is that files permissions are affected by the containing directories permissions. Sure, I can’t read, write nor execute the file, but I can delete it!
So here is another great example of why you should not chmod 0777 all the things!
What about when everyone needs access to a directory?
OK, so sometimes there are times when you need to have read-write-executable permissions for everyone on the system. A fantastic example is the /tmp directory. How do we work around that?
You might now be asking, “Hang on, how come I can’t delete another user’s files in /tmp?”. Well, this is what I am alluding too.
You may have noticed that instead of writing chmod 777, I have been writing chmod 0777, the full octal notation. This is purposely done because there are a series of values that can be set before the 777, called special permissions. Namely, setuid (4), setgid (2), and the Sticky bit (1).
The special permissions on /tmp are important to consider as these provide other permissions based functions such as stopping you from deleting other user’s directories and files.
What does the sticky bit look like?
Below are the permissions for /tmp that show that the sticky bit is enabled:
[ manningx@example:/ ] $ ls -lahd tmp
drwxrwxrwt 13 root root 4.0K Jan 8 15:56 tmp/
Notice the t on the end of the directories permissions. This directory has the following permissions applied to it:
# chmod 1777 /tmp
or:
# chmod +t /tmp
Let’s try this on our previous example to see it in action. First, I am going to add the sticky bit to the ~/testdir directory.
[ manningx@example:~/testdir ] $ sudo chmod +t ../testdir/
Now, let’s try to delete that file:
[ manningx@example:~/testdir ] $ ls -lah
total 8.0K
drwxrwxrwt 2 root root 4.0K Jan 8 15:52 ./
drwxr-xr-x 16 manningx manningx 4.0K Jan 8 15:17 ../
-rw------- 1 root root 0 Jan 8 15:52 filetodelete
As you can see, the sticky bit (t) is applied to ~/testdir.
[ manningx@example:~/testdir ] $ rm filetodelete
rm: remove write-protected regular empty file ‘filetodelete’? y
rm: cannot remove ‘filetodelete’: Operation not permitted
[ manningx@example:~/testdir ] $ ls -lah
total 8.0K
drwxrwxrwt 2 root root 4.0K Jan 8 15:52 ./
drwxr-xr-x 16 manningx manningx 4.0K Jan 8 15:17 ../
-rw------- 1 root root 0 Jan 8 15:52 filetodelete
[ manningx@example:~/testdir ] $
By Jove! I can’t delete filetodelete, it’s still there!