Weakness reference
CWE-277

Insecure Inherited Permissions

This weakness occurs when a newly created resource file, directory, process, or object automatically inherits overly permissive access controls from its parent…

01Summary

This weakness occurs when a newly created resource (file, directory, process, or object) automatically inherits overly permissive access controls from its parent or a template, allowing unintended users or processes to read, modify, or execute it. The developer assumes inherited permissions are safe without explicitly validating or restricting them, creating a gap between intended and actual access levels.

02How It Happens

When operating systems or frameworks create new resources, they often apply default permissions based on the parent resource, umask settings, or system defaults. A developer may create a sensitive file or directory expecting restrictive permissions, but if the parent directory is world-readable or the process umask is too permissive, the new resource inherits broader access than intended. This is especially common in temporary file creation, configuration directories, log files, and process spawning, where the developer focuses on functionality rather than explicitly hardening permissions at creation time.

03Real-World Impact

An attacker with local access to the system can read sensitive data (API keys, database credentials, user information) stored in files with inherited overly-permissive permissions. In some cases, inherited write permissions allow modification of executable files or configuration, leading to privilege escalation or code execution. Inherited permissions on temporary directories can enable race conditions or allow unprivileged users to inject malicious content into processes running with higher privileges.

04Vulnerable & Fixed Patterns

Vulnerable pattern
import tempfile
import os

# Create a temporary directory for storing sensitive config
temp_dir = tempfile.mkdtemp()
config_file = os.path.join(temp_dir, "app_config.txt")

with open(config_file, "w") as f:
    f.write("database_password=secret123")

# File inherits default umask permissions — likely world-readable

Why it's vulnerable:
The temporary directory and file are created with default permissions, which may allow other users on the system to read the sensitive configuration data.

Fixed pattern
import tempfile
import os

# Create a temporary directory with restrictive permissions
temp_dir = tempfile.mkdtemp(mode=0o700)
config_file = os.path.join(temp_dir, "app_config.txt")

with open(config_file, "w") as f:
    f.write("database_password=secret123")

# Explicitly set file permissions to owner-only
os.chmod(config_file, 0o600)
Vulnerable pattern
<?php
// Create a directory for storing uploaded files
$upload_dir = "/var/www/uploads/user_data";
mkdir($upload_dir);

// Store sensitive user information
$user_file = $upload_dir . "/user_" . $user_id . ".txt";
file_put_contents($user_file, $sensitive_data);

// Directory and file inherit default umask — may be world-readable
?>

Why it's vulnerable:
The directory and file are created without explicit permission restrictions, inheriting the system's default umask, which may grant read access to other users or the web server group.

Fixed pattern
<?php
// Create a directory with restrictive permissions
$upload_dir = "/var/www/uploads/user_data";
mkdir($upload_dir, 0700, true);

// Store sensitive user information
$user_file = $upload_dir . "/user_" . $user_id . ".txt";
file_put_contents($user_file, $sensitive_data);

// Explicitly restrict file permissions
chmod($user_file, 0600);
?>

05Prevention Checklist

Explicitly set permissions at creation time.
Use mkdir(mode=0o700), open(mode=0o600), or equivalent when creating sensitive files and directories; do not rely on inherited or default permissions.
Audit parent resource permissions.
Before creating child resources, verify that parent directories and containers have appropriately restrictive permissions.
Use secure temporary file APIs.
Prefer tempfile.NamedTemporaryFile() (Python) or tmpfile() (PHP) over manual temporary directory creation, as they enforce restrictive defaults.
Set umask before resource creation.
If creating multiple resources, set the process umask to a restrictive value (e.g., 0o077) before creation, then restore it afterward.
Document permission assumptions.
Clearly comment on expected permission levels for sensitive resources so future maintainers do not accidentally relax them.
Test with least-privilege accounts.
Verify that resources created by your application are not readable or writable by unprivileged users or other processes.

06Signs You May Already Be Affected

Check whether sensitive files or directories in your application are readable by other system users or the web server group. Use ls -la or stat to inspect permissions on configuration files, temporary directories, and log files. If you find files with permissions like 644 or 755 that contain credentials, API keys, or user data, inherited permissions may have granted unintended access.

07Related Recent Vulnerabilities