A file can be readable only by its owner and still be exposed. Another user may be able to replace it through a writable parent directory, a backup may have looser permissions, or an application may follow a symbolic link to an unexpected destination. The mode shown by ls -l is only one part of the picture: you also need to know who can reach the path and which processes handle the data.
Start with paths, not just files
Linux resolves a pathname one directory at a time. To reach a file, a user needs search permission, shown as x, on every directory in the path. Directory read permission, r, allows names to be listed. Directory write permission, w, together with search permission, allows changes to entries. Someone who cannot read a file's contents may still be able to delete or rename it if they have the necessary permissions on its containing directory.
Take a private key at /home/ada/.ssh/id_ed25519. Restrict the key itself, but check the directories leading to it as well. On systems with namei, run namei -l /home/ada/.ssh/id_ed25519 to inspect each component. For mode notation and common access failures, see the blog's Linux File Permissions: Read, Change, and Troubleshoot Access. Here, the focus is how those permissions interact with the rest of the file system.
Shared directories need special attention
A world-writable directory is not necessarily unsafe. /tmp, for example, is meant to hold temporary files for multiple users and normally has the sticky bit set, displayed as drwxrwxrwt. The sticky bit generally stops users from removing or renaming one another's entries just because the directory is writable. It does not make file contents private or protect an application that mishandles a predictable filename. Applications should use facilities that choose unique temporary filenames and open them atomically.
Ownership includes the processes running as that owner
Linux checks a process's credentials, not the intentions of the person who started it. A web service running under a dedicated account should be able to own or write only the paths it needs. If that account can change the service's executable, its configuration containing secrets, and its published content, one application fault could affect all three.
Keep application code read-only to the service where practical, and give it write access to a specific upload or cache directory rather than the whole project tree. Use stat to inspect a path's owner, group, mode, and timestamps, and id to check group membership. Verify the credentials of the service process too; your interactive account may have different access.
Creation defaults matter. A process's umask removes permission bits from newly created files and directories; it never adds them. With conventional creation modes, a umask of 077 typically results in private files and directories. Programs can request narrower modes, and changing the umask does nothing to existing files. Test it in the service's actual launch environment rather than assuming your shell configuration applies.
Watch for access rules beyond the mode bits
Owner–group–other permissions do not tell the whole story. Access control lists (ACLs) can grant permissions to specific users or groups beyond those basic classes. On a system using POSIX ACLs, a + after the mode in ls -l is a cue to check getfacl. A directory's default ACL can also affect files created inside it. If access seems surprising, compare the ACL, ownership, group memberships, and permissions on every parent directory before changing anything.
Mandatory access controls add another layer. SELinux labels or AppArmor profiles may block a process even when ordinary permissions appear to allow access. These policies constrain processes, but they do not replace sensible ownership and modes. If access is denied, inspect the distribution's logs and policy tools instead of making a sensitive file world-readable as a test.
Mount options can change behavior as well. noexec restricts direct execution from a mount, while nosuid disables set-user-ID and set-group-ID effects there. Neither stops a process from reading a script and passing it to an interpreter, and neither replaces application isolation. The overview of file-system permissions provides a cross-system reference; check your Linux distribution for operational details.
Protect the data across its full lifetime
Links, moves, and replacements
A symbolic link is a pathname that points elsewhere. If a privileged program writes through a link in a location an untrusted user can modify, it may change the wrong file. Hard links give the same inode additional names, which can complicate assumptions about where data exists. For routine administration, inspect unexpected links with ls -l and resolve a path with readlink -f where available. That resolution is only a snapshot: the path could change afterward. When developers handle untrusted paths, directory-relative and no-follow file-opening facilities are safer than checking a path separately and then opening it.
Moving a file within one filesystem commonly preserves its ownership and permissions. Copying creates a new file whose metadata depends on the tool, options, destination, and privileges. Check the result rather than assuming the copy is as restricted as the source. Apply the same care to archives, whose extracted ownership and modes may not suit the destination.
Backups, deletion, and encryption
Backups and snapshots are additional copies with their own access controls. A private database file is still exposed if every local account can read its backup. Check who can read the backup destination, how restoration handles ownership and ACLs, and whether the restored application account gets only the access it needs. Before relying on the procedure, test a restore with non-sensitive data.
Deleting a pathname does not reliably erase sensitive bytes from modern storage. Copies may remain in snapshots, backups, journals, or storage hardware. Full-disk or filesystem encryption helps protect data on lost or powered-off devices when the keys are unavailable; it does not hide files from a logged-in process that already has read permission. Restrict live access, and manage backup keys separately from the data they protect.
A small, authorized audit
On a machine or lab you administer, pick one sensitive application directory and trace how it is accessed:
- Identify the service account and the directory holding its sensitive files.
- Inspect each parent directory, then check file ownership, modes, and any ACLs.
- Confirm which subdirectories the service actually needs to write.
- Look for copies, backups, or shared temporary locations that expose the same data.
- Test access as the intended service identity and as an ordinary account, without weakening production permissions.
Suppose a service needs to append logs under /var/log/example-app. Check that it can write there but cannot alter its installed program files. If either test fails, adjust the narrowest relevant directory or service setting and run both tests again.
