Command line quick tips: Permissions

Image by Ryan Lerch (CC BY-SA 4.0)

Fedora, like all Linux based systems, comes with a powerful set of security features. One of the basic features is permissions on files and folders. These permissions allow files and folders to be secured from unauthorized access. This article explains a bit about these permissions, and shows you how to share access to a folder using them.

Permission basics

Fedora is by nature a multi-user operating system. It also has groups, which users can be members of. But imagine for a moment a multi-user system with no concept of permissions. Different logged in users could read each other’s content at will. This isn’t very good for privacy or security, as you can imagine.

Any file or folder on Fedora has three sets of permissions assigned. The first set is for the user who owns the file or folder. The second is for the group that owns it. The third set is for everyone else who’s not the user who owns the file, or in the group that owns the file. Sometimes this is called the world.

What permissions mean

Each set of permissions comes in three flavors — read, write, and execute. Each of these has an initial that stands for the permission, thus r, w, and x.

File permissions

For files, here’s what these permissions mean:

  • Read (r): the file content can be read
  • Write (w): the file content can be changed
  • Execute (x): the file can be executed — this is used primarily for programs or scripts that are meant to be run directly

You can see the three sets of these permissions when you do a long listing of any file. Try this with the /etc/services file on your system:

$ ls -l /etc/services
-rw-r--r--. 1 root root 692241 Apr 9 03:47 /etc/services

Notice the groups of permissions at the left side of the listing. These are provided in three sets, as mentioned above — for the user who owns the file, for the group that owns the file, and for everyone else. The user owner is root and the group owner is the root group. The user owner has read and write access to the file. Anyone in the group root can only read the file. And finally, anyone else can also only read the file. (The dash at the far left shows this is a regular file.)

By the way, you’ll commonly find this set of permissions on many (but not all) system configuration files. They are only meant to be changed by the system administrator, not regular users. Often regular users need to read the content as well.

Folder (directory) permissions

For folders, the permissions have slightly different meaning:

  • Read (r): the folder contents can be read (such as the ls command)
  • Write (w): the folder contents can be changed (files can be created or erased in this folder)
  • Execute (x): the folder can be searched, although its contents cannot be read. (This may sound strange, but the explanation requires more complex details of file systems outside the scope of this article. So just roll with it for now.)

Take a look at the /etc/grub.d folder for example:

$ ls -ld /etc/grub.d
drwx------. 2 root root 4096 May 23 16:28 /etc/grub.d

Note the d at the far left. It shows this is a directory, or folder. The permissions show the user owner (root) can read, change, and cd into this folder. However, no one else can do so — whether they’re a member of the root group or not. Notice you can’t cd into the folder, either:

$ cd /etc/grub.d
bash: cd: /etc/grub.d: Permission denied

Notice how your own home directory is setup:

$ ls -ld $HOME
drwx------. 221 paul paul 28672 Jul 3 14:03 /home/paul

Now, notice how no one, other than you as the owner, can access anything in this folder. This is intentional! You wouldn’t want others to be able to read your private content on a shared system.

Making a shared folder

You can exploit this permissions capability to easily make a folder to share within a group. Imagine you have a group called finance with several members who need to share documents. Because these are user documents, it’s a good idea to store them within the /home folder hierarchy.

To get started, use sudo to make a folder for sharing, and set it to be owned by the finance group:

$ sudo mkdir -p /home/shared/finance
$ sudo chgrp finance /home/shared/finance

By default the new folder has these permissions. Notice how it can be read or searched by anyone, even if they can’t create or erase files in it:

drwxr-xr-x. 2 root finance 4096 Jul  6 15:35 finance

That doesn’t seem like a good idea for financial data. Next, use the chmod command to change the mode (permissions) of the shared folder. Note the use of g to change the owning group’s permissions, and o to change other users’ permissions. Similarly, u would change the user owner’s permissions:

$ sudo chmod g+w,o-rx /home/shared/finance

The resulting permissions look better. Now, anyone in the finance group (or the user owner root) have total access to the folder and its contents:

drwxrwx---. 2 root finance 4096 Jul  6 15:35 finance

If any other user tries to access the shared folder, they won’t be able to do so. Great! Now our finance group can put documents in a shared place.

Other notes

There are additional ways to manipulate these permissions. For example, you may want any files in this folder to be set as owned by the group finance. This requires additional settings not covered in this article, but stay tuned to the Magazine for more on that topic soon.

For System Administrators

11 Comments

  1. Tom

    Paul – The finance group isn’t shown in the final ls of the /home/shared/finance directory.

  2. OlivierS

    I think when you :
    sudo chgrp finance /home/shared/finance
    You should have
    drwxr-xr-x. 2 root finance 4096 Jul 6 15:35 finance
    and not
    drwxr-xr-x. 2 root root 4096 Jul 6 15:35 finance

    A mistake in images i think but at the end
    drwxrwx—. 2 root root 4096 Jul 6 15:35 finance
    seems not to be correct too because in this case just user “root” and group “root” can access “finance”

  3. Great and timely article Paul!

    I’ve recently returned to Fedora from Ubuntu due to my concerns about $PRIVACY over $CONVENIENCE in the default umask=0022 of Ubuntu(and Debian). How I missed these defaults in Ubuntu’s /etc/adduser.conf(DIR_MODE=0750) and /etc/login.defs for so many years is a matter of some embarrassment for me and ought to be for Ubuntu/Debian, as well.

    All one has to do is look signpost’s such as the GDPR or the Equifax data breach for clues as to why ‘open'(world readable) $HOME dirs is a very bad idea for $DEFAULTS.

    Thank you for bringing the remedy and highlighting the point in your post, as Fedora uses $SANE defaults in this regard.

    BTW: I started my journey with Linux by purchasing a boxed-set of “RED HAT 8.0” at a CompUSA store for $39.00. Fedora was still just a gleam in some developer’s eyes.

  4. Errrrr…

    :%s/DIR_MODE=0750/DIR_MODE=0755/g , above, as 0750 is my change to the default of 0755.

    :%s/look signpost’s/look to signpost’s/g , above, proof-b4-post!

  5. Jarek

    I am very grateful for these articles. Could the next advanced article also explain the use of numbers with the permission system? A person can see those a lot when searching for some solutions (or reading specfiles 🙂 ) regarding the permissions

  6. Yuri Oliveira

    I would add that we can use numbers to change permissions:

    read: 4
    write: 2
    execute: 1

    And we would sum up the permissions for each category (user, group, others). For a

    drwxr-xr-x

    permission, we’d have

    rwx = 4+2+1 = 7
    r-x = 4+0+1 = 5
    r-x = 4+0+1 = 5

    So, if you’d like to change the permissions of the

    finance

    shared folder from

    drwxr-xr-x

    (755) to

    drwxrwx---

    (700), that would be:

    sudo chmod 770 /home/shared/finance
  7. NotEnough

    And what about 2775 ?

  8. we4

    and create finance user
    and change own
    chown finance.finance

  9. fdelapena

    Thanks! Another interesting permissions feature not quite popular is ACL (getfacl/setfacl) for fine-grained control for users and groups.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions