2026-10-28 · By Todd Michael Gori
Expected Versus Actual: Reading Access in a Folder You Own
A small, owned test folder can teach you how to predict access before you check it, then record where your prediction and the observed result disagree.
Why predict before you check
Many beginners look at file permissions and simply accept whatever they see. A more useful habit is to write down what you expect first, then compare that expectation with what the system reports. The gap between expected and actual is where learning happens. Linux file access permissions distinguish the file owner, group and others, and read, write and execute bits mean different things for regular files and directories. Keeping those meanings straight is much easier when you have made a prediction and tested it.
This exercise stays inside a disposable directory that you create and own on your own machine. Nothing here targets a system you do not control. The goal is only to build careful observation habits, which is the same discipline described in standard technical testing guides such as NIST SP 800-115, which emphasizes planning, recording scope and analyzing findings rather than acting on assumptions.
A worked example
Suppose you create a folder called notes-lab inside your home directory and place a file called sample.txt inside it. Before running any command, write three predictions in a notebook: the owner of sample.txt can read it, the owner can write to it, and the file can be executed or not. Then inspect the permission string with a listing command and compare each prediction against the bits you see.
Now imagine the listing shows read and write for the owner but no execute bit. Your prediction that the file is not executable matches. But if you had guessed that a text file automatically gains execute permission, you would have learned something useful from the mismatch. Record the difference in your own words. A hypothetical reader might write: expected execute absent, observed execute absent, lesson: text files do not become runnable because they exist in a folder I made. This is an original illustrative example, not a claim about any particular system's defaults.
A small exercise and a checklist
Exercise: create one empty folder and one text file inside it, then write down your prediction for read, write and execute for the owner, group and others. Check the result and note any mismatch. Do not change permissions yet. Observe first, and only consider a change if you can explain why it is safe in your own owned folder.
Checklist, in plain sentences: confirm the folder is one you created and own; write predictions before checking; record observed bits exactly as shown; note mismatches and your reasoning; remember that a single listing describes one moment and does not prove the whole system is secure; delete the test folder when finished. Limitations matter here, because permission bits are only one layer of how access is controlled, and a clean result in a toy folder does not establish how a real environment behaves.