Linux fundamentals
Linux File Permissions Coding Interview Problem
Written and reviewed by Sahil Srivastav
What this interview round tests
Linux file permissions interviews show up because backend engineers routinely debug broken deploys, unsafe config trees, and secrets that are readable by the wrong users. The commands look familiar - chmod, chown, umask, stat, and find - but the interview grading usually comes down to whether you can make every path land in a deliberate, auditable state.
This challenge is built for that exact round. Instead of answering permission trivia in isolation, you fix a shell script in a repository, run the bundled tests, and prove that secrets, configs, and directories all end up with the intended ownership and mode-bit posture.
The scenario
You are handed a provisioning script for an application config directory. The service refuses to start cleanly because the generated tree mixes unsafe permissions with inconsistent defaults.
A secret file is too exposed, a config file is broader than it needs to be, and a blanket permission change leaves room for group or other write access under the tree. The starter repository fails its shell tests; your job is to harden the setup behavior while preserving the intended file layout.
What you’ll practice
- Reading Linux mode bits with stat and validating them through tests
- Using chmod deliberately instead of broad recursive permission changes
- Reasoning about owner, group, and other permissions for secrets and configs
- Understanding how umask affects files created after the script starts
- Auditing a tree with find so no file remains group- or other-writable
- Writing shell changes that are secure, repeatable, and easy to review
How to approach it
Start from the failing tests and map each assertion back to the artifact it protects. Separate directories, ordinary config, and secret material into different permission roles, then trace the script in creation order so inherited defaults do not undo the hardening work.
Avoid treating the tree as one uniform blob. The robust path is to make permission intent explicit per artifact, verify the resulting modes with standard Linux tools, and use a final audit sweep to catch anything that still allows group or other writes.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Is this a chmod and chown interview question?
Yes. It focuses on the practical side of chmod, ownership thinking, umask, and permission audits. You work in a real shell repo, not a quiz, so the answer has to satisfy executable tests that inspect the filesystem state.
What do interviewers test with Linux file permissions problems?
They want to see whether you can reason from risk to mode bits: secrets should not be broadly readable, config files should be usable without becoming writable, directories need traversal bits, and recursive chmod shortcuts can create security bugs.
Does the page reveal the exact fix?
No. The public page explains the interview shape and the skills involved. The starter repository contains the failing contract, and Gronex Pro includes the reviewed solution after you work through the challenge.