Checking File Permissions in Linux with ls

As a Linux system administrator, it‘s important to understand file permissions and how to check them. The ls command provides a simple way to view the permissions settings on files/directories.

In this comprehensive 2600+ word guide, we will cover:

• Linux File Permissions Explained
• Using ls to View Permissions
• Interpreting ls Permission Output
• Advanced ls Permission Options
• Permission Best Practices
• Ownership & Groups
• Security Implications
• Comparing with stat & namei
• Troubleshooting Issues

Linux File Permissions Explained

On a Linux system, every file/directory has assigned permissions controlling access:

• Read (r) – View or list contents
• Write (w) – Modify or delete contents
• Execute (x) – Run a file or enter a directory

For each object, permissions are assigned to the owner, group members, and all other users.

In addition, Linux has extended permission types:

• Setuid (SUID) – s – Run file with permissions of the owner
• Setgid (SGID) – s – Run file with group permissions
• Sticky bit – t – Restrict deletion by other users

These special permissions allow for additional access controls in multi-user environments.

Permission Codes

Putting all those options together, Linux permissions can be represented by a 10 character code like:

-rwsr-xr-t

Breaking this down:

• First dash – Indicates a regular file
• Next 3 (rw-) – Owner permissions
• Fourth (s) – SUID enabled for owner
• Next 3 (r-x) – Group permissions
• Eighth (r) – Other user read permission
• Ninth (t) – sticky bit set

Understanding how to interpret these permission codes is critical for administration.

Using ls to View Permissions

The most common way to check file permissions is with the ls command.

In its simplest form, ls displays permissions of visible files/folders in the current directory.

$ ls -l
total 12
-rw-r--r-- 1 john staff  413 Feb 12 file1.txt
drwxr-xr-x 2 john staff 4096 Feb 12 folder1

The first column shows the 10-character permission code, followed by ownership details, size/date, and finally name.

Some key points on reading this ls output:

• First dash indicates `file1.txt` is a regular file
• Owner (john) has read/write permission
• Group/world users have read-only access
• `folder1` is a directory with execute rights for owner/group/world

This provides a snapshot of the access controls set on these objects. Next we‘ll cover more advanced usage of ls.

Interpreting Complex Permission Codes

When viewing permissions across a Linux server, you may encounter more complex examples like:

brw-rwS--- 1 root disk 8, 16 Feb 12 /dev/sdd1

Here we have special permissions indicating a block device file, with read/write for root and the disk group. The S flag also shows the SGID bit is set on the group permissions.

Or another multilayered example:

-rwsr-Sr-t 1 john staff 326 Feb 12 /usr/local/bin/helper

This executable file grants the owner SUID privilege plus enables the sticky bit. The group has the SGID permission to access file with staff group rights.

There are many permutations of special modes that can show up in ls output. Being able to decode them is critical for administration, security auditing, and troubleshooting file access issues.

Advanced ls Permission Options

ls has several handy options to extract additional permission details:

Recursive Directory Listings

ls -lR /opt/myapp

Apply permission listing recursively including subdirectories. Useful for auditing consistency.

Toggle Ownership ID vs Name

ls -ln
-rwxr-x--- 1 502 20 4096 Feb 12 file.txt

Shows numeric UID/GID instead of name. Simplifies parsing output programmatically.

Toggle Group Info

ls -log
-rwxr-x--- 1 john 4096 Feb 12 file.txt

Omit group name/ID from listing. Focus just on owner + permissions.

There are also options to append indicators like (/) on directories and (*) on executables, adding colors, showing full timestamp info, and exporting output to CSV format.

Mastering these ls arguments allows gathering permissions data for monitoring, alerting, analysis and automation.

Linux File Permission Best Practices

To enhance security when setting permissions, some key tips include:

• Restrict broad recursive world permissions
• Carefully review SUID/SGID files and minimize use
• Set umask 027 or 077 default creation mask
• Apply least privilege principal to users/groups

Adopting simplified permission schemes makes auditing easier. Standards like CIS Linux Benchmark provide additional recommendations.

Top causes of insecure configurations are overly broad recursive permissions and unused SUID/SGID privileges. Checking those areas with ls is a good starting point.

User Groups & Ownership

Managing Linux permissions goes hand-in-hand with controlling user groups and ownership.

Where possible, have files owned by actual users rather than generic ones like root or daemon. Use groups to collect users by access level, department, app-type, or other criteria to streamline administration.

Analyze group membership along with permissions checks during audits. The output of ls -l and groups together provide that context to make adjustments.

Security Implications

Improperly configured Linux permissions open doors to malicious activity through:

• Data exposure – Overly broad read access enabling snooping of sensitive files
• Data destruction – Unnecessary write access allowing deletion/modification of important files
• System exploitation – Write + execute permissions giving ability to replace binaries with backdoors

Using ls to perform frequent permission checks, particularly on paths like /bin, /etc and /var, allows getting ahead of such risks.

Look for unusual write access for standard users on critical files, as this may indicate intrusions. Permissions down to the world/other level should also be most restrictive.

Comparing ls to stat & namei

While ls is simplest way to check file permissions, there are a couple other handy commands:

stat – Show file metadata including permission code

stat /etc/shadow
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)

More verbose details in a structured format.

namei – Trace file path resolving symbolic links

namei -l /usr/bin/python3.6
f: /usr/bin/python3.6
 dr-xr-xr-x root root /
 drwxr-xr-x root root usr
 drwxr-xr-x root root bin
 lrwxrwxrwx root root python3.6 -> python3
 -rwxr-xr-x root root python3

Helper for tracing files that may have their permissions unexpectedly altered by symlinks.

So while ls is most common, stat and namei have some additional visibility that‘s handy situationally.

Troubleshooting Permission Issues

Here are some examples of using ls to troubleshoot permission-related problems:

Application failing to write to logs:

ls -ld /var/log/myapp
drwxrwxrwx 2 root root 4096 Feb 12 /var/log/myapp

Wrong owner and public write access allows logs to be accidentally deleted.

PHP scripts failing with permission errors:

ls -l /var/www/html
total 8
-rw-rw-r-- 1 user1 user1  443 Feb 12 index.php

The PHP interpreter needs at least execute access to function.

Database showing authorization failures:

ls /var/lib/postgresql/data/pg_hba.conf 
-rw-r----- 1 postgres root 3523 Feb 12 /var/lib/postgresql/data/pg_hba.conf

Postgres conf file should have postgres owner and restrict global access.

These examples showcase common cases where ls can identify the culprit permission issues behind system problems.

Summary

Mastering the use of ls for reviewing file permissions is a must-have skill for Linux administration. Pay careful attention to the permission codes, ownership/groups, and special modes output. Combine it with groups and stat for additional visibility.

Set permissions following least privilege principals and audit against CIS Linux Benchmarks. Be extra stringent on monitoring for risky recursive permissions and SUID/SGID binaries.

Following the best practices outlined here for utilizing ls will help proactively lock down your Linux environment and troubleshoot issues more swiftly.