HackBlue

Tools · Linux command line for security · 01 / 28

Linux file permissions explained: rwx, octal chmod, and ls -l

Read the ten characters at the start of ls -l, convert them to octal, and choose chmod values for scripts, keys, and shared folders.

11 min read · practice only with authorization

Reading ls -l

Run ls -l and the first column looks like -rwxr-x---. The first character is the type: a dash for a regular file, d for a directory, l for a symlink. The next nine are three groups of three for the owner, the group, and everyone else. Each group shows read (r), write (w), and execute (x), or a dash when the bit is off.

On directories the bits mean something slightly different. Read lets you list names, write lets you create, delete, and rename entries, and execute lets you enter the directory and reach files inside it. A directory with r but not x lets you see filenames but not open any of them.

Octal in one minute

Each permission has a value: read is 4, write is 2, execute is 1. Add them per group. rwx is 7, r-x is 5, r-- is 4, and --- is 0. So rwxr-x--- is 750 and rw-r--r-- is 644. chmod 640 file gives the owner read and write, the group read, and others nothing.

Symbolic mode does the same with letters: chmod g-w,o= file removes write from the group and clears others. Symbolic mode is safer for small adjustments because it only changes what you name.

Snippet
ls -l /etc/shadow /etc/passwd ~/.ssh/id_ed25519
chmod 640 report.txt
chmod u=rwx,g=rx,o= deploy.sh
stat -c "%A %a %U:%G %n" deploy.sh

Lab: fix three common mistakes

Create a private key file, a shell script, and a shared team folder in a lab VM. Set the key to 644, the script to 777, and the folder to 777, which are the mistakes you will meet in real systems. Then fix them: the key to 600 so only its owner reads it, the script to 750 so the team can run it but not edit it, and the folder to 2770 with a group owner so team members share files and outsiders see nothing.

Use stat to confirm each value. SSH itself will refuse a private key that others can read, printing “UNPROTECTED PRIVATE KEY FILE”, which is a good example of software enforcing the rule for you.

Snippet
sudo groupadd -f analysts
mkdir -p /srv/team && sudo chgrp analysts /srv/team
chmod 600 ~/.ssh/id_ed25519
chmod 750 deploy.sh
sudo chmod 2770 /srv/team
stat -c "%a %n" ~/.ssh/id_ed25519 deploy.sh /srv/team

Why 777 is a finding

Mode 777 lets any local account, including a compromised web server user, change the file. If that file is a script run by root from cron, anyone who can write it can run commands as root. When you see 777 on anything executable or on a directory in a privileged path, treat it as a privilege escalation path and fix it.

Prefer the smallest mode that works and use groups to share. If you are tempted to use 777 to make something work, the real fix is almost always a correct owner or group.

Diagram

Common modes and where they belong

Pick the mode from the file’s job.

  • 600

    Private keys, credential files, personal configs.

  • 644

    Public readable files such as most of /etc.

  • 750

    Scripts a team can run but not change.

  • 2770

    Shared team directory with inherited group.

  • 777

    Almost never. Anyone can change it.

Check yourself

1. What octal value is rwxr-x---?

2. What does the execute bit on a directory allow?

3. Why is a root cron script with mode 777 dangerous?