Opening Framing: Data Does Not Forget
In Week 2, you learned that processes are temporary — they start, run, and terminate. In Week 3, you learned that identity is contextual — it exists within sessions and execution contexts. Now we confront something that outlasts both.
Filesystems introduce a different kind of problem.
Data persists.
Users log out. Processes terminate. Sessions expire. But files often remain — quietly carrying assumptions about trust that no longer exist.
This week introduces a core systems-security idea explicitly:
Data persistence beyond identity.
1) Files Are Not Owned the Way People Think
In everyday language, we say someone "owns" a file. In operating systems, ownership is not about possession — it is about authority attribution.
A file's metadata records:
- Which user created it
- Which group it is associated with
- What actions are allowed
None of this changes automatically when:
- A user leaves an organisation
- A role changes
- A process terminates
Mental model: files remember past trust decisions long after people forget them. Ownership is attribution, not possession — the system records who created it, not who should have access now.
2) Data Persistence Beyond Identity (Explicit Concept)
We now name the phenomenon directly.
Data persistence beyond identity describes the fact that:
- Files outlive processes
- Files outlive sessions
- Files often outlive users and roles
The filesystem does not ask whether the original trust context still makes sense. It simply enforces recorded rules.
Many real-world breaches involve no new access being created — only old access never being reconsidered.
Key insight: the filesystem doesn't ask "should this still be true?" It only enforces what was recorded. Security requires humans to review and revoke — the system won't do it automatically.
3) Authority vs Access
It is tempting to equate "having access" with "having authority". Filesystems make this distinction very clear.
Authority answers:
- Who may grant or revoke access?
- Who may change permissions?
Access answers:
- Who can read?
- Who can write?
- Who can execute?
Security failures often occur when access is audited, but authority is ignored.
Key insight: access control asks "who can read this?" Authority asks "who can change who can read this?" Both matter, but authority is often forgotten.
Real-World Context: Data Persistence as Attack Surface
Data persistence creates security risks that outlast the circumstances that created them:
The Uber Breach (2016): Attackers found AWS credentials stored in a private GitHub repository. Those credentials were created months earlier and never rotated. The data persisted; the need for those specific credentials did not. 57 million user records were exposed because secrets outlived their safe context.
Exposed S3 Buckets: Hundreds of organizations have been breached through misconfigured S3 storage buckets. The pattern is consistent: someone creates a bucket, sets permissions for a specific purpose, and those permissions persist long after the original purpose changes. Data persistence beyond identity — the bucket doesn't know the person who configured it has left the company.
Log File Exposure: Applications write logs containing sensitive data — API keys, session tokens, personal information. Those logs persist on disk, in backups, in log aggregation systems. The application that wrote them may be gone; the data remains. MITRE ATT&CK documents credential harvesting from files as technique T1552.001.
Common thread: files remember what processes forget. Credentials, configurations, and sensitive data persist until explicitly removed — and explicit removal rarely happens.
Guided Lab: Observing Persistent Authority
This lab focuses on seeing how authority and access are recorded in the filesystem, and how those records persist independently of users and processes.