How does chmod 755 work?

What chmod 755 actually changes

chmod 755 changes the permission bits on a Unix-like file or directory. The first digit, 7, gives the owner full access, read, write, and execute. The second and third digits, both 5, give group and other users read and execute only. On directories, that usually means they can list and traverse the directory, but not add or replace files.

That makes 755 a common choice for executable programs, web-accessible scripts, and directories that must be readable by others but not writable. It is less appropriate for content that should remain private, because “read” for group and others is still broad exposure even when write access is withheld.

Why 755 is common, and why it is not a safe default everywhere

755 is popular because it supports normal execution without forcing everyone to use the owner account. For a binary or script, the execute bit is what allows the system to run it, while the read bit lets users inspect it. For a directory, execute on the directory means the ability to enter it or access items within it when the name is known, which is why 755 often appears on shared application paths.

That convenience can become a security issue when 755 is treated as a blanket default. A file that is readable by everyone may expose source code, configuration fragments, command names, or operational logic. A directory that is readable and traversable by everyone can also reveal naming patterns and file structure, which can help an attacker or simply expose more than intended.

For defenders, the critical question is not whether 755 “works”, but whether the object should be world-readable and world-executable in the first place. If the object can influence execution flow, service startup, or privileged automation, write access is the real danger, because a writable script or service file can be replaced or altered and then executed later with more trust than it deserves.

How to read 755 in practice, and what to check before using it

When you see 755, break it into three independent decisions: ownership, group access, and public access. The owner usually needs the most privilege because they are expected to maintain the file. The group should only have what shared operational use requires. “Others” should be granted only when the file or directory is truly meant for broad use.

For executable files, 755 is often acceptable when the code is public or operationally shared, but it should be reviewed carefully on scripts, cron jobs, init files, and application launchers. For directories, 755 is often fine for program directories and static content roots, but not for locations where untrusted users might create or replace content.

On systems where multiple people or services interact with the same paths, the key check is whether any non-owner can modify something that later gets executed or trusted. If they can, the permission model is too loose even if the mode number looks conventional. In that situation, ownership, group membership, and the parent directory permissions matter as much as the file mode itself.

Risk and Threat Considerations

755 becomes risky when it is applied to files that should not be broadly readable, or when it is combined with a writable path elsewhere in the execution chain. An attacker does not need 755 itself to be dangerous, they need a path where a readable or executable object can be replaced, influenced, or discovered in a way that supports later abuse.

Failure mechanism: A script, service file, or directory is made too permissive, allowing an unprivileged user to read sensitive logic, discover operational details, or swap in malicious content when write access exists somewhere in the chain. If that object is later executed or loaded by a higher-privilege process, the permission weakness becomes a code-execution or persistence path.

Impact: The practical outcomes include tampering with startup files, altering automation behaviour, exposing sensitive implementation details, and enabling privilege escalation when a trusted process runs a modified file. Even without direct escalation, overly broad readability can make targeted abuse easier by revealing what will run, where it lives, and how it is invoked.

Practitioner Guidance

What to verify: Confirm whether the file or directory genuinely needs public read and execute access, and verify that no unprivileged user can write to it or to a parent path that controls it. If a service file or script is involved, inspect the entire execution path, not just the final mode.

Decision rule: If the object is operationally sensitive, treat “755 by default” as a red flag and justify each bit explicitly. If users only need to run a program, read access may be acceptable, but write access should remain tightly controlled and ownership should reflect the real maintainer.

Practitioner takeaway: 755 is a convenience setting, not a security guarantee; the important judgement is whether the object can be safely read and executed by everyone without creating a path for tampering, disclosure, or later abuse.

Related resources from NHI Mgmt Group

• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?
• When should teams prioritise NHI governance over other IAM work?