Read, write, execute, and chmod

02Decode classes before adding values

The listing begins with a file-type character, such as - for a regular file, followed by three groups of permissions. Read those groups in order: owner, owning group, others. The owner is the user who owns the file; the owning group is its assigned group. Others covers users outside the first two classes.

Choose one class before deciding access. The owner uses the owner class even if also a group member. A non-owner in the owning group uses the group class; remaining users use others. Do not add rights from all three classes.

Numeric modes use octal, a base-eight numbering system whose digits are 0 through 7. For each permission digit, use read=4, write=2 and execute=1. Add only the present rights within each class. Thus 6 is read plus write, 4 is read alone, and 0 gives none. The worked 600 mode gives owner read/write and no group or other rights.

For the paper activity, decode 620: owner 6 means read/write; group 2 means write only; others 0 means none. A non-owner group member can modify content but does not gain read through those group bits. This separates choosing a class from assuming all writers can read.

Assume ordinary mode checks here: no access-control list, root override, other special privilege or blocked parent directory. An access-control list, abbreviated ACL, adds access rules beyond this simple display. In real troubleshooting, mode bits alone may be incomplete evidence.

For a directory, r allows listing names and x allows traversal, meaning reaching entries by name. With needed traversal, w allows changing directory entries. Removing a filename therefore depends mainly on the containing directory rather than on writing that file's content. Other restrictions can also apply.

03Use a fresh owned workspace

The paths lesson introduced ~/yanosec-lab: ~ expands to your home directory. Before a file activity, return with cd ~/yanosec-lab. Use pwd to check your location and ls -a to inspect names. Continue only if this is your recognized owned lab. Then create the lesson's new child directory.

If mkdir reports that a destination already exists, preserve that work. Choose an unused name and use it consistently, or follow the paper route. Enter one command at a time and continue only after the preceding step succeeds. Record an unexpected result before doing anything else.

Unless the lesson says otherwise, leave the small activity folder for review and return with cd ~/yanosec-lab when finished. Closing the terminal does not delete files you saved. These activities need no sudo or system-file changes.

04Try an owned note mode

Only a new harmless regular file receives a mode change. chmod changes permission bits; it does not change file content or ownership. ls -l requests a longer listing that includes the displayed mode.

Follow the numbered steps only inside a new rights directory. The initial mode may vary. The worksheet supplies the expected before/after interpretation, so the paper route can trace a mode change without changing any real file. Keep that prediction separate from the check cards later on the page.

Read a mode one class at a time

First identify owner, owning group or others for the accessing user.
Then read that class only. Numeric modes use octal, base eight, with
digits 0 through 7. Within each digit, add the values of present rights.
Fresh paper activity: mode 620 gives group write without group read.
Explain why the owner still uses the owner class.

Assume ordinary mode checks only:
no ACL, root override, other privilege or ancestor access problem.
Class order: owner, group, others. Bits: read=4, write=2, execute=1.
Worked mode 600: owner rw; group none; others none.
Activity mode 640: owner rw; group r; others none.
Directory primer: r lists names; x traverses; w with x can modify entries.
File write and permission to delete its directory entry are distinct.
Activity fresh permission-note.txt: harmless practice note (newline).
Inspect before/after chmod 640; predict mode prefix -rw-r-----.
Question: a group member who is NOT the file owner accesses a regular
file with mode 640. Can that role write through the stated mode? yes/no

harmless practice note

1. From the lab root, create mkdir rights and enter cd rights only after success. Write printf '%s\n' 'harmless practice note' > permission-note.txt in that fresh directory.
2. Inspect ls -l permission-note.txt; record the initial mode and actual owner privately. Default creation permissions may vary with the creation mask, a setting that removes default rights, so do not expect a fixed initial mode.
3. Run chmod 640 permission-note.txt. Inspect ls -l again. Expected mode prefix: -rw-r-----. No owner/group name or timestamp is fixed.
4. Decode each class and explain why a non-owner group member lacks write under the stated ordinary-mode assumptions. You do not need another real user account or a failed write attempt to reason from the card.
5. Restore this disposable file's private owner mode with chmod 600 permission-note.txt if desired, then return to the lab root and retain it. The paper route traces before/after modes without changing any file.

05Optional challenge

Allow about ten extra minutes. A regular file is readable, but its parent directory lacks traversal permission for the accessing user. Explain why the readable file bits alone do not establish that the user can reach it. Compare this with deleting an entry from a writable directory.

06Cards for the checks

The checks below use these cards. They are original fictional text, safe to read anywhere.

1-rw-r--r--  1 maya staff  88 notes.txt
2-rw-rw----  1 maya staff  41 shared.txt
3-rwx------  1 maya staff 120 run.sh
4-r--r--rw-  1 maya staff  12 odd.txt

07Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Mode prefix: -r--rw---x
The first character describes the regular-file type.
Read the remaining positions in owner, owning-group, others order.

Columns: mode | owner | owning group | filename
-r--r----- | Ivo | editors | brief.txt
-r-----rw- | Ivo | editors | decoy.txt
-r--rw---- | Ivo | editors | draft.txt
-rw---x--- | Ivo | editors | tool.txt
 
Actor: Nia belongs to editors and owns none of these regular files.
Assume accessible parent directories, ordinary mode checks, no ACLs,
no privilege overrides, and no other restriction on these content writes.

Columns: mode | owner | owning group | filename
-r-xrw-rw- | Kai | reviewers | report.txt
Actor: Kai owns report.txt and also belongs to reviewers.
Questioned operation: writing the regular file's contents.
Assume accessible parent directories, ordinary mode checks, no ACLs,
no privilege overrides, and no other restriction on content writes.

Columns: mode | owner | owning group | path
drwxr--r-x | Mara | readers | cabinet/
-rw-r--r-- | Mara | readers | cabinet/note.txt
Actor: Sol belongs to readers and owns neither entry.
Sol already knows the exact filename and wants to read its contents.
The path goes through cabinet. Earlier path components are accessible.
Assume ordinary mode checks, no ACLs or privilege overrides, and no other restriction.

Columns: mode | owner | owning group | filename
-r--rw---- | Ivo | editors | revision.txt
Intended change: let owner Ivo write the file contents as well as read them.
Keep every current group and others permission exactly as shown.
Do not add execute for anyone. Change only the necessary owner permission bit.
This is a paper mode calculation; no real file change is requested.

08Explain an access decision

Optional self-check: explain one denied access decision in three sentences. State the actor's relationship to the file or directory, the one class that applies, and the permission needed for the operation.

Check your explanation: do not combine classes or fall back to others after a denial. For a path, distinguish directory traversal from reading file contents. Keep the ordinary-mode assumptions beside your conclusion; real access can also depend on additional access rules and privileges.