Hello,
This video is an introduction to Linux filesystem permissions.
I will explain what permissions are, how file ownership and group association works,
and how to change permissions to control file access for yourself and other users on your system.
Understanding filesystem permissions is very important.
Many users, even experienced ones, are confused about them
and see permissions as something they simply ‘turn off’.
(I am using air quotes here)
They set permissions that are too broad or unnecessary, failing to keep their files private
and possibly compromising their system’s security.
Each file and directory on a Linux filesystem has a set of permission flags,
which outline who can do what with them.
We can see current file permissions using ls command by adding ‘-l’ option, which gives us the long listing.
I have here in my ‘example’ directory a file called ‘password.list’
and a directory called ‘sources’.
Right now, I am the only one who can read and write ‘password.list’ file,
while ‘sources’ directory is shared with other users on the system.
Character 1 shown in the first column of ls command output describes the file type,
for example a ‘d’ indicates a directory, while a '-' indicates a regular file.
Permissions are shown as characters 2 through 10 in this column.
Current permissions are indicated by various characters with letters ‘r’, ‘w’, 'x'
and ‘-’ being the most common.
The meaning of these is mostly self-explanatory:
‘r’ stands for ‘read’, ‘w’ stands for ‘write’ and ‘x’ stands for ‘execute’.
For regular files, ‘read’ means the file contents can be viewed or the file can be copied.
‘Write’ permission means the file contents can be changed.
While, ‘execute’ means the file is a program which can be run.
The file type and permissions are shown together for a reason.
While they look similar for regular files and directories,
their effect is different depending on file type.
In this video I will focus on regular files and discuss directory permissions in the next lesson.
The 9 permission characters in the permission string are logically tied in threes.
The first 3 permission characters apply to ‘user’, otherwise known as ‘owner’ of the file.
Characters 4 through 6 apply to the group ‘user’ belongs to,
while characters 7 through 9 apply to everyone else, collectively referred to as ‘others’.
In the context of filesystem permissions, ‘groups’ are collections of system accounts
which can share files with each other by controlling permissions on them,
while ‘others’ refers to everyone else.
Such 3-tier breakdown allows file owners to control access to their files
for themselves and the other two communities separately.
It is worth noting that permissions do no apply to the system administrator (called ‘root user’)
who has unrestricted access to the entire filesystem.
You cannot use permissions to prevent ‘root’ user to access your files, including the ability to delete them.
Each subset of the three permission characters always comes in the ‘r’, ‘w’, ‘x’ order.
If a specific letter is visible, then that permission is set (or allowed),
otherwise there is a ‘-’ in its place.
The owner of a file controls permissions on that file,
and file ownership and group association is established when a file is created.
The long ls output shows file ownership and user group association.
Column 3 tells us who owns the file, while column 4 displays which group may have access to it.
I am currently logged in as user ‘pi’ and this user belongs to a group ‘pi’.
You can always check your group association using ‘id’ command.
User ‘pi’ happens to belong to several user groups,
but ‘pi’ group is set as default for that user, so any files user ‘pi’ creates,
will be associated with ‘pi’ group.
File ownership and group association typically is not changed.
The system administrator has the option to change these parameters using restricted commands,
but regular users normally cannot do it.
Permissions on the other hand can be changed by the users, for all files and directories they own.
Let me create a new file called ‘monday.txt’ using nano editor.
I will put some text into it, so the file is not zero in size to make it a bit more interesting
than if I just used the ‘touch’ command to create an empty file.
Here it is!
A new file, however made, receives a default set of permissions when created,
which in this case is ‘read’ and ‘write’ permission for me and ‘read’ permissions for group and others.
Default permissions are a system setting which varies between Linux distributions.
Each user can customize the defaults and I will show you how to do that in the next lesson.
You would be rightfully concerned seeing that the ‘group’ and especially ‘others’
have read access to my newly-created file by default.
Depending in which directory a file is created, this could mean that my new file is ‘world-readable’.
It is possible that the entire Internet can read this file right now,
as ‘others’ really mean ‘everyone’.
Linux filesystem permissions as a concept, were invented decades ago,
in a different, smaller and more trusting world.
For better or for worse, this open access philosophy remains in place.
Unfortunately, you will not have a secure system unless you manage permissions properly.
Existing permissions are changed using ‘chmod’ command (sometimes pronounced ch-mod),
which stands for ‘change file mode’.
The permission flags are manipulated for ‘user’, ‘group’ and ‘others’
using standard ‘+’, ‘-’ and ‘=’ mathematical operators
which respectively add or subtract from permissions already set, or override them.
For example, here is how I would add ‘write’ permission for group, for ‘monday.txt’ file.
This command reads as: change permissions for ‘group’ by adding ‘write’ flag to file ‘monday.txt’
Or, here is how I would take away ‘read’ permission from ‘others’.
This command reads as: from others remove ‘read’ permission.
Now, ‘others’ have no permissions to ‘monday.txt’ file at all.
It is important to note that the middle portion of the command does not have any spaces
around the mathematical operator.
The only spaces used here, separate the command, permissions, and the filename from each other.
We can ‘add’ and ‘remove’ permissions at the same time.
For example, now I will take away ‘write’ permission, while adding ‘execute’ flag for myself.
Notice how ‘monday.txt’ filename changed colour in ls command output,
now that ‘execute’ flag designates it as a program.
The ls command uses colour to distinguish between different file types.
Regular files are shown in white by default, directories are blue and programs are green on my system.
We can change permissions for user, group and others at the same time with a single command.
For example, now I will take away ‘write’ permission from ‘group’ and add ‘read’ permission for ‘others’.
In such scenario, the permissions for different entities are separated by a comma.
Again, the only spaces used are between the command and permissions,
and between permissions and the file name.
Beginners routinely put spaces around the comma, which is incorrect syntax,
resulting in an error message.
We can combine ‘u’ ‘g’ and ‘o’ letters in chmod command if setting the same permissions for them.
For example, If I would like to add ‘write’ permission for myself and others...
I could do it like this...
But the command can be shortened like that...
This time there is no comma in the permission token.
A comma is only used when different permissions are set for ‘user’, ‘group’ or ‘others’.
As you can probably guess, setting the same permissions for everyone
uses all 3 indicator letters – ‘u’, ‘g’, ‘o’, like this....
But for that special case, we can use ‘a’ indicator, which stands for ‘all’, to shorten the command.
For example, now I will take away ‘write’ permissions from ‘all’...
In this case ‘group’ did not have ‘write’ permission to begin with.
The ‘chmod’ command will always try to apply permissions as specified,
but it will not complain if the permissions are already the correct ones.
The ‘=’ operator clears existing permissions and assigns new ones.
Some users find this operator easier to understand than ‘+’ or ‘-’
and it’s really a matter of personal preference which one they use regularly.
For example, now I will make sure that ‘group’ has no permissions
while ‘others’ have only ‘execute’ permission.
Setting permissions to ‘=’ to ‘blank’ means ‘set the permissions to nothing’.
By the way, you cannot permanently lock yourself out from accessing your own files
by taking away your own permissions.
You can always set permissions later to get the access back.
For example....
I will remove all permissions from ‘monday.txt’ file, so no one can access it.
And now I give myself ‘read’ and ‘write’ permissions to the file.
All right!
Now that you have an idea how to change permissions,
let me explain how specific permissions affect command line behaviour.
Permissions for regular files describe what can be done with the file contents,
applicable to ‘user’, ‘group’ and ‘others’ separately.
In general, most user-created files will have (or should have)
‘read’ permission and ‘write’ permissions set for the file owner,
and no permissions for group and others, just like you see with my ‘password.list’ file.
This is typically sufficient or appropriate for day-to-day file access,
allowing us to view, copy and change the contents of files we own, while securing them from outside access.
Permissions for ‘group’ and ‘others’ should only be granted when needed.
The ‘write’ flag can be removed to make the file ‘read-only’,
assuming that ‘read’ permission is set of course,
providing some protection against changing the file contents accidentally.
The ‘execute’ flag is assigned rarely to regular files,
only to program files which are meant to be executed directly.
Most user-created files are typically not programs, so they would not have that flag set.
I will focus on ‘read’ and ‘write’ permissions for now
and will have a separate video to introduce shell scripting,
where I will explain the use of ‘execute’ flag with regular files.
My ‘pasword.list’ file has ‘read’ and ‘write’ permissions right now for me.
The ‘read’ permission allows me to access or view the file contents,
for example by opening it in a text editor such as nano.
There is some content in the file, so it was read and displayed by the editor.
In the editor, I can change existing or add new contents, including making the file blank.
Because I have ‘write’ permission, I can make these changes permanent by saving the file.
I save the updated file and exit the editor.
Looking at the file details, I can see that it has increased in size to account for the text I just added to it.
Read permission also allows me to copy the file, for example for the purpose of making a backup.
Notice that the permissions of the copied file are same as the original.
Default permissions do not apply in this case,
and ‘group’ and ‘others’ did not get the default ‘read’ access to the backup file.
Should I change permissions on the backup file, for example by making it read-only,
it will have no effect on the original file’s permissions.
While the files have identical contents right now, they are separate entities
and have their own permission settings.
When I open the backup file in the nano editor, I get a warning that the file is unwritable.
Should I make changes to the contents and attempt to save,
the editor will refuse, citing ‘permission denied’.
Having said that, ‘read’-only permission for regular files we own is soft
and it can be temporarily overridden.
Many commands have a way to ignore the missing ‘write’ permission
and still make changes to read-only files we own,
without us having to change the permission first.
For example, the vi editor, a more advanced tool than nano, allows changes to read-only files.
Here, when I attempt to save the changed file using standard ‘write’ command,
I will get a warning too.
However, this editor offers me an option to save this file despite being ‘read’-only,
using a modified write command,
by adding an exclamation mark to the standard vi editor write command.
You can see that the file is now smaller, as i was able to save the changes in the vi editor,
despite not having ‘write’ permission.
It is important to understand that permissions for regular files control what can be done with the file contents,
not what can be done with the file itself.
Many Linux users, including experienced ones, do not understand this important distinction,
mistakenly believing that making a file read-only will prevent them from being overwritten or deleted.
My ‘backup’ file is read-only,
but I can still override it, using ‘cp’, ‘mv’ or ‘rm’ commands if I use ‘-f’ (force) option.
Here is a forced rm command example with the read-only ‘backup’ file.
No prompt, no warning, ‘backup’ file is gone!
Ultimately it is the directory permissions, where the file is listed,
and not the individual file permissions that control what can be done with the file itself.
I will revisit this important nuance in my next lesson, where I explain permissions for directories.
All right! Let’s explore how permissions set for our files affect how other users can access them.
Let me use another terminal where I will log in as user ‘bob’.
‘bob’ is a member of group ‘pi’, which my original account ‘pi’ belongs to as well.
This means that user ‘bob’s’ access to files associated with ‘pi’ group
is controlled by the middle 3 flags of the permission string.
Right now, ‘bob’ has no access to ‘password.list’ file.
Any attempt to view or copy the file as user ‘bob’ will be met with a ‘permission denied’ error.
For example, when I use a text editor...
User ‘pi’ can grant read access to ‘password.file’ file to ‘pi’ group,
therefore allowing ‘bob’ to access the file...
Now ‘bob’ can copy the file or view the file contents,
although the original file it is still unwritable to user ‘bob’.
Any attempts to change the file as user bob will be met with a ‘permission denied’ message.
How about granting ‘write’ permission to ‘group’?
Well... this is a bit more complicated.
Allowing open write access to your files for ‘group’ or especially ‘others’
carries considerable risk and needs to be done very carefully.
It’s a broad topic and I will discuss it in a separate lesson.
Let’s try another user for read access...
Now I am logged in as user ‘alice’.
Account ‘alice’ is not a member of group ‘pi’, therefore ‘alice’ accesses ‘password.list’ file as ‘others’.
Right now ‘alice’ cannot access the password file as ‘others’ have no permissions to it.
I will get a ‘permission denied’ error if I try to copy it as user ‘alice’...
That will change if user ‘pi’ will set permissions, for example allowing others to ‘read’ the file.
Now ‘alice’ can access the file, and perform operations such as ‘copy’.
User ‘pi’ can take away the access to ‘password.list’ file for ‘others’ at some point later,
but ‘alice’ gets to keep the copy.
That’s it for the file permission basics.
The next video will discuss permissions for directories.
I will also introduce a numerical method for changing permissions
and show you how to change the permission defaults.
Thanks for watching!