2026-10-23 · By Todd Michael Gori
Scoping a Permissions Exercise Before You Touch Anything
A practical way to turn a technical reading into a small, owned, and reversible lab on Linux file permissions, with a written scope and a clean finish.
Why the Scope Comes First
Reading about file permissions is easy. Doing something with them safely takes a little more thought. Linux file access permissions distinguish the file owner, the group, and others, and the read, write, and execute bits mean slightly different things for regular files than they do for directories. Before you change a single bit, decide where the exercise is allowed to happen. The safest answer is a disposable directory that you own, created for the purpose and nowhere near shared or production data.
Treat the scope as a short written note rather than a vague intention. Name the directory, state what you will observe, and say what you will not do. This habit comes from structured security testing practice, which emphasizes planning, recording observations, and analyzing results. NIST SP 800-115, a 2008 guide, describes technical testing in those terms and also notes the limits of such techniques, so a small self-made lab should be read as learning, not as proof that a system is secure.
A Worked Example
Suppose you create a directory called permlab inside your home folder and place two files in it: notes.txt and script.sh. You list them with ls -l and record the owner, group, and permission string for each. You then remove the write bit from notes.txt for the owner and try to append a line to it. The write fails, and you note the error message and the permission string that caused it. Next you consider the directory itself. Removing write permission from permlab would stop you from creating or deleting files inside it, even though the files themselves might still be readable. Writing those predictions down before you run each command, then comparing them with the result, is the core of the exercise.
This example is hypothetical, written to illustrate the method. It is not a claim about how any particular system is configured, and your own results may differ depending on your user, group membership, and filesystem.
A Small Exercise for You
Create a new empty directory named practice-perms in a location you own. Place one text file inside it. Before changing anything, write down the current permission string and your predictions for three changes: removing read permission, removing write permission from the file, and removing execute permission from the directory. Apply one change at a time, run a simple read or write attempt, and record what happened. When you finish, restore the original permissions and delete the directory and its files. Note one thing that surprised you and one question you still have.
Keep in mind that this exercise only covers the basic owner, group, and other bits in a single environment. It does not establish how permissions behave under access control lists, containers, network shares, or any system you do not control.
Checklist Before You Finish
Confirm that the directory is one you created and own. Write the scope and expected observations before running commands. Change one permission at a time and record each result. Restore original permissions and remove all test files. Note limitations, such as what this environment does not cover. Keep any further testing within systems you own or are explicitly authorized to assess. Review your notes and decide what to study next, such as directory semantics or ownership changes.
If any step feels unclear, pause and reread your scope note. A short, bounded exercise that you finish cleanly teaches more than a sprawling one you cannot account for.