Exercise 1: Why SQLite Has No User/Permission System — Possible Solution
====================================================================

THE STRUCTURAL REASON, TIED TO SQLITE1-1'S ARCHITECTURE
------------------------------
Per this chapter, "sqlite1-1's own 'no server' model means there's
genuinely nothing analogous to MySQL's user accounts or Postgres's own
roles — there's no server process to authenticate against in the
first place, so the entire concept of database-level user permissions
has no place to live in SQLite's own architecture." Per sqlite1-1,
MySQL and Postgres both run as "a separate server process... listening
on a network port," and a user/role system exists specifically to
control WHO is allowed to connect to that server process and WHAT
they're allowed to do once connected. SQLite has no such server
process at all — connecting to a SQLite database just means opening a
file directly through an in-process library call. Since there's no
server standing between the application and the data to authenticate
against, there's structurally nothing for a "user account" concept to
attach to — the entire mechanism MySQL/Postgres roles exist to control
access to simply doesn't exist in SQLite's own model.

WHAT FILLS THE GAP INSTEAD
------------------------------
Per this chapter, "access control for a SQLite database is entirely a
matter of operating-system file permissions (who can read or write the
actual .db file) plus whatever the application itself chooses to
implement." Instead of the database engine itself enforcing who can
read or write specific data, that responsibility shifts to two
different places: (1) the operating system's own ordinary file
permission system, controlling which OS-level users/processes can even
open the database FILE at all, and (2) the application built on top
of SQLite, which can implement its own access-control logic (e.g. a
login system, role checks within the app itself) if the use case
genuinely needs differentiated access for different people using the
same application.

WHY THIS IS "DIFFERENT," NOT SIMPLY "WORSE"
------------------------------
Per this chapter, "this is a genuinely different security model, not
simply a lesser one — but it does mean the application and its
deployment take on responsibility that MySQL/Postgres would otherwise
absorb at the database layer itself." The chapter is explicit that
this shifts responsibility rather than eliminating it — SQLite doesn't
provide LESS security by default so much as it relies on a DIFFERENT
layer (the OS and the application) to provide it, consistent with this
whole course's own throughline that SQLite solves a different problem
than MySQL/Postgres.

WHY THIS WORKS AS AN ANSWER
------------------------------
It traces the absence of a user/permission system directly back to
sqlite1-1's own no-server architecture, and names precisely which two
layers (OS file permissions, application logic) take over that
responsibility instead, rather than treating the absence as an
unexplained gap.