Understanding the often complicated file permissions on the Bash CLI (Linux, Mac OS X and WSL)

Background

This article was originally published on Dataquest Direct, a learner's magazine on Dataquest.io, where I serve as a Community Moderator to help others learn about Data Science and technology in my free time. I often not only discuss and help answer technical questions, but also engage in meaningful exchanges with students and my fellow volunteers. Feel free to check me out there!

Note that I am not paid by them to write such an article and opinions and expressed here are solely mine. Please get in touch with me if there are any errors or shortcomings so that I can rectify them for the benefit of others! Also note that I greatly simplified how the UI looks for simplicity and to help beginners understand the concepts that I will be presenting.

Introduction

I have recently received quite a few questions about Command Line Permissions in the Community. In this article, I will be addressing how we can go about dealing with permissions on terminals using the Bash scripting language. Note that I will not be doing a deep dive into Bash scripting or the filesystem so please check out the links at the bottom of the article for more information about the language, syntax and its origins.

Linux, Mac OS X and Windows Subsystem for Linux (WSL) are variants based on the Unix architecture. Although there are slight differences in file structure, the Bash commands used generally achieve similar effects (although what is done under the hood in the OS is likely to be different).

Why are permissions important? The simplest analogy is in a multi-user Operating System. Let us say that you are the administrator and you do not want someone who shares the same computer as you, or a different user from snooping at your files--to do this you will need to impose permissions on them in order to restrict access where needed.

If you have gone through the command line missions or played around with the terminal yourself, you would have realized that whenever you create a file using your favourite text editor like Vim, Leafpad or Nano or through the command line, the file will usually be automatically assigned permissions upon creation.

1. How to create a sample text file

Again I will not go into step-by-step detail. This is a brief overview.

Here are some samples of how to create a text file through the command line:

I personally prefer Vim because of its simplicity.

$ vim test.txt
<editor window opens>
<press i for insert>
...
<type whatever you want to type>
...
<To save, press Esc, followed by colon (:) wq. To discard, press Esc, followed by colon (:) q!>
<you will be automatically returned to the CLI window>

or you can do:

echo "Hello there" > my_first_file

which redirects the string "Hello there" into a file named my_first_file, or the like... and thereafter you can view the file created by doing an ls -l (long listing of the directory to view the contents of it).

Generally files can be created with your home folder but you will need elevated privileges to create them in other directories like tmp, bin and sbin.

2. Why are predefined permissions important?

They give you just the right amount of permissions to do standard tasks with the file. This helps to implement what security people call the Principle of Least Privilege, which is assigning just the right amount of permissions for the task a user needs to do with the file.

When a file is created, minimally read permissions are granted to all user types (owner, group and others)--more on that in a bit. This helps to save you from accidentally deleting an important OS-related file or a configuration files--usually .ini or .conf files in Linux , which could be devastating to your system especially if you do not have a backup of these files.

3. Basic Scripting syntax and terminology

Before getting started, I think it is important for us to know some basic syntax and terminologies (non-exhaustive).

Do a long listing of files in the current directory

$ ls -l

Display the current working directory to the screen (or print working directory)

$ pwd

Change Directory (to move around the file system)

$ cd

The Current Directory (Notation)

$ .

Navigate to the Parent Directory (the directory above the current one)

$ cd ..

Execute a file (run the specified file in the current working directory)

$ ./<filename>

Other notations:

~: specifies your home directory (where your Desktop, Download, Images and many more folders are)
/: specifies the root directory or the mother of all directories

Terms:

root user: administrator equivalent in the Windows world
home directory: equivalent to C:\Users\<username> on Windows

4. How to interpret permissions

Alright, now that I have introduced some scripting syntax we shall move on to the real deal...

a) The three basic permissions and their corresponding numeric representations

r (read) -- 4
w (write) -- 2
x (execute) --1

Doing a long listing of the current directory (i.e. ls -l) will give something like this: (Note: I truncated the unimportant parts off so usually you will see a more verbose output.)

$ ls -l
-rwxr-xr-x  p.exe
-rwxr-xr--  x.txt

which is a set of permissions and the corresponding file name.

b) Directory/File Permissions

Wow its complex isn't it? Yes! It is for a first-timer, so don't worry. The left half takes the following syntax:

 -                  rwx        rwx          rwx 
[directory]        [owner]    [group]  [other user]

The first character is a hyphen - if the object is a file (and not a folder) otherwise its a d which stands for directory (or a folder). The following (first) triad consists of the permissions assigned to the owner--that is the user who created the file. Note that owners can be changed (but I will not be going into it in this article). The second triad is for the group in which the file is shared with and the third triad is the other user. Note that a hyphen - may replace any one of the characters in these 3 triads, which means that the permission at that particular bit is not set.

-rwxr-xr-x

So for this example, the object is a file since it does not have a d as the first character. The owner has read, write and execute permissions on the file, the group and other users have only read and execute permissions.

c) Best Practices

In the security industry, we generally assign users to groups and give permissions to the groups rather than give them to individual users for the following reasons:

less administration needed
if the only user who has access to the file account got deleted, access to the file is essentially gone forever
restriction of access (e.g. Sales group should not have rwx permissions on HR's folders etc)

So I may create say a test group and give them limited access to the resources on specific folders/directories on my computer (more on that in the linked playlist below and perhaps in a future article).

5. Changing Permissions and Elevating Privileges

Sometimes, we need to access to more permissions (say we need to be able to write to a file to resolve an error) and be really careful when doing this (I would suggest a backup if possible). We can then use the chmod (change mode) command.

To make a backup, we can use the copy (cp) command with the following syntax.

cp <source_directory>/<source_filename+extension> <destination_directory>/<destination_filename+extension>.bak

Cumulative permissions (1 or more) should be the sum of the numbers I have written next to the permissions above. A list detailing all the possible combinations is included below for your reference:

--x (execute only): 1
-w- (write only): 2
-xw (write and execute): 3
r-- (read): 4
r-x (read and execute): 5
rw- (read and write): 6
rwx (read, write and execute): 7

The chmod syntax is as follows:

$ chmod <permissions> <filename>

Note that besides numbers as arguments passed to the command, we can also use the + and - operator to add or remove permissions. For example:

chmod u+x test.txt

The above command adds execute permissions for the owner of the file (test.txt).

chmod o-w test.txt

This removes write permissions for other users more on that here. Despite that, I prefer to use the numeric system and so I shall use it in the example and my explanations from this point onward.

Using the previous example:

$ ls -l
-rwxr-xr-x  p.exe
-rwxr-xr--  x.txt
$ chmod 744 x.txt
/home/kali/.bashrc: Permission denied

In this instance, although we tried to change the permissions, it failed because we have insufficient privileges (i.e. not the root user). We thus need to escalate our privileges--to have more rights to conduct certain tasks. To do this, use the sudo command or "substitute/super user do". Note you will be asked for your sudo password and when you enter it, the cursor will not move but rest assured, it is being taken in as input.

For other commands that you would like to execute in sudo mode, simply prepend this in front and you will get administrator/root user access. In the past admin would be prompted for their sudo password everytime they needed to execute something in sudo mode. Nowadays, the makers of linux decided to instead have a timeout. So you can use as many commands prepended with sudo for 10 to 15 minutes and thereafter you are prompted for your password again.

⚠️ Danger: Please also do not misuse this suffix in front of other commands (do not type it unless you know exactly what the suffix command does).

$ sudo chmod 744 x.txt
(will prompt you to enter sudo password)
$ ls -l
-rwxr-xr-x  p.exe
-rwxr--r--  x.txt

Now the group and others for x.txt only have read permissions.

Conclusion

Thanks for taking the time to read this lengthy article and I hope it provided you a little insight towards dealing with permissions. I personally used a wonderful playlist on YouTube by Eli the Computer Guy for using the Linux CLI and will link that, together with some other useful articles I found useful about permissions (though there are many more resources out there on the Internet). I will also include links to DQ articles where I addressed questions regarding permissions.

Happy learning!