2026-10-29 · By Todd Michael Gori
A One-Page Evidence Log for Reading Permissions in Your Own Lab Folder
A small, owned-folder session becomes far more useful when every observation is written down with its limits. Here is a simple evidence log template and a way to use it.
Why a Log Beats Memory
When you read file permissions in a practice folder, it is easy to finish with a vague sense of what you saw. Two weeks later you may not remember which account you tested as, what the owner and group were, or whether a change was something you made or something that was already there. A short written log fixes this. Linux file access permissions separate the owner, the group and others, and the read, write and execute bits mean different things for regular files and for directories, so a single note like "permissions looked fine" hides most of the detail that matters. The NIST technical testing guide makes a related point in its own terms: findings should be recorded and analyzed, and the limits of any technique should be stated rather than assumed away. A log is the lightweight version of that discipline for a personal learning session.
The log also protects you from overclaiming. An observation is what you saw on one system at one moment. It is not a statement about every system, and it is not a security conclusion on its own. Writing the observation and the limitation side by side keeps those two things from drifting apart.
Hypothetical example: a reader creates a folder called permtest inside a home directory they own, makes two files and one subdirectory, and runs a listing. The log records the exact command output, the user the session ran as, and the note that the folder was created for this exercise and will be deleted at the end. Nothing outside that folder was touched.
A Worked One-Page Template
Keep the log to one page so it actually gets filled in. Use these plain fields, in this order. Date and time. Owned location: the exact folder you created, described in words, not a system path you do not control. Account used. Scope statement: one sentence saying what you are examining and what you are not examining. Observations: numbered lines, each with the object name, the owner, group and permission string as displayed, and one sentence on what the reader believes the bits mean for that object type. Limitations: what this session could not show, such as the fact that a listing does not reveal effective access under every account, or that you did not check inherited settings elsewhere. Cleanup: the command or step that removed the test folder, and a yes or no confirming it is gone.
A worked example entry might read: observation 2, file notes.txt, owner the session user, group the session user's primary group, permission string showing read and write for the owner and read only for the group and others. Belief: the owner can change the contents, others can only view. Limitation: this does not confirm what a different account could do if ACLs or other mechanisms were present, and the lab did not test that. Cleanup: test folder removed, confirmed by a second listing showing no such folder.
A Small Reader Exercise and a Checklist
Try this on a folder you own. Create a practice directory, add one file and one subdirectory, and fill in a single log page using the template above with at least three observations. Then reread your limitations section and ask yourself two questions: which claim in my observations depends on something I did not check, and what would I need to write down to make that dependency visible to a future reader? These are reader questions, not recommendations from the sources about your exact workflow.
Checklist for your next session. Is the folder one you created and own. Is the scope stated in one sentence. Is each observation tied to a named object and a recorded permission string. Is every belief about the bits labeled as a belief. Did you write at least one limitation. Did you remove the test files and confirm it. If any answer is no, fix the log before you start the next exercise.
Limitations of this approach: a log records your reading, not the truth about a system you have not examined. It does not replace a formal assessment, and it does not certify anything. It is a habit for keeping your own observations honest.