Exercise 2: Column-Level Grant for a Profile Widget — Possible Solution
====================================================================

GRANT SELECT (id, display_name, avatar_url) ON users TO 'profile_widget'@'%';

WHY THIS WORKS AS AN ANSWER
------------------------------
The column list in parentheses — (id, display_name, avatar_url) — is
what makes this a COLUMN-level grant rather than a table-level one.
Only those three named columns become readable to this account; every
other column on the users table, including email and password_hash,
remains completely inaccessible to it, even though the grant is
technically "on" the same users table those sensitive columns live in.

This matters concretely: if the profile_widget service's own code had
a bug — say, an unvalidated query that let an attacker request an
arbitrary column name — the DATABASE ITSELF would refuse to return
password_hash or email to this account regardless of what the buggy
application code tried to ask for, because the privilege to read those
specific columns was never granted in the first place. This is the
same "defense in depth" idea from this chapter's SQLi cross-reference,
applied at the column level: the account's own privileges act as a
second line of defense even if the application layer above it fails.