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.
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.
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.
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?