A developer fixes a permissions problem on a Linux server by running `chmod -R 777` over an application's directory tree. What is wrong with that, and how would you set permissions correctly on a tree that mixes directories and data files?

## Why 777 is the wrong answer to any question Mode `777` grants read, write and execute to every account on the machine. For an application tree that means: - **Any local process can rewrite the code.** A compromised unrelated service, a shared CI account, a second tenant on the box — anything running as any UID can edit a script or a configuration file that your application later loads and executes. This converts "attacker has some local access" into "attacker runs code as your service account", which is the escalation step you were supposed to prevent. - **Any local process can rewrite the data**, silently, with no audit trail beyond filesystem timestamps. - **Nothing is protected from accident either.** World-writable is also everyone-can-truncate. And it very often does not even fix the original problem, because the original problem is frequently ownership or a missing search bit on a parent directory rather than the modes on the files themselves. `777` is applied because it is the biggest hammer available, not because it addresses the diagnosis. ## Why recursion makes it worse `chmod -R` applies one mode to two fundamentally different kinds of object. Directories need `x` to be traversable; plain data files should almost never have `x`. So *every* recursive numeric chmod is wrong in one direction or the other: - `chmod -R 755` — directories are correct, and now every data file is executable. - `chmod -R 644` — files are correct, and every directory has lost its search bit, so the tree becomes unreachable and even `ls -l` returns question marks. - `chmod -R 777` — both are "working" and everything is world-writable. ## The destructiveness is the part people miss There is no journal of previous modes. Before the recursive chmod the tree may have held a private key at `600`, a socket directory at `750`, and a handful of helper scripts at `755`. Afterwards that structure is simply gone, and the security-relevant ones are the ones you most needed. Recovery means reconstructing intent: - For files owned by a distribution package, the package manager can restore the modes it recorded — RPM-based systems expose this directly (`rpm --setperms <package>`), and on Debian-based systems the package's recorded metadata plus reinstallation serves the same purpose. - For application files, from your deployment tooling or configuration management, which is the real argument for having permissions declared there rather than applied by hand. - For anything else, from a backup — or from judgement. Before any wide chmod, capture the current state so the change is reversible: a listing of every path with its octal mode and owner is a few seconds of work and turns an irreversible operation into a reversible one. ## Doing it correctly **Split by object type.** Directories and files get different modes: ``` find /srv/app -type d -exec chmod 750 {} + find /srv/app -type f -exec chmod 640 {} + ``` **Or use symbolic mode with capital X.** In `chmod`, `X` means "execute, but only for directories, or for files that already have at least one execute bit set". That makes a single recursive pass safe: ``` chmod -R u=rwX,g=rX,o= /srv/app ``` Directories become `750`, ordinary data files become `640`, and existing executables keep their execute bit. Lowercase `x` in the same command would have marked everything executable — the case of the letter is the whole difference. **Fix ownership as well as mode.** Most "permission denied" reports are really ownership problems: `chown -R app:app /srv/app` and then grant write only in the specific subdirectories the service writes to. A tree where code is owned by a deploy account and readable-but-not-writable by the runtime account is meaningfully harder to attack than one where the service can rewrite its own code. **Grant the narrowest thing that works.** If a group needs access, add the group and use `640`/`750` rather than opening to others. If exactly one extra account needs one file, that is what per-file access-control entries exist for. ## A caution about recursion itself `chmod -R` operates on what it walks. It does not change the permissions of symbolic links themselves, and it will not descend into a symlinked directory by default — but a tree containing bind mounts or a symlink you did not expect can still put you somewhere you did not intend. Know what is under the path before you recurse over it, and never recurse from `/` or a home directory root. ## What a good answer sounds like Name the security consequence first (world-writable code is remote-ish code execution for any local foothold), then the correctness consequence (files should not be executable, directories must be), then the operational one (the previous modes are unrecoverable), and finish with the type-split or capital-`X` technique plus fixing ownership. Saying "it works but it's bad practice" is not enough — the interviewer wants the specific mechanism of harm.