Exercise 1: Reading Through an fd You Never Opened Fails, Not Silently — Possible Solution
====================================================================

THE TEST
------------------------------
    owner_fd = syscalls.invoke(owner.pid, 'open', '/secret')
    syscalls.invoke(owner.pid, 'write', owner_fd, 0, b'CLASSIFIED')

    # intruder never calls open() at all
    syscalls.invoke(intruder.pid, 'read', owner_fd, 0, 10)

RESULT
------------------------------
    intruder calling read(fd=0, ...) without ever opening anything
    raised: KeyError(8)
    the genuine owner's own read still works correctly: b'CLASSIFIED'

The intruder's own call fails immediately with a KeyError; the
owner's own legitimate read is completely unaffected afterward.

WHY THE INTRUDER'S CALL FAILS
------------------------------
_do_read()'s own implementation is:

    def _do_read(self, pid, fd, offset, length):
        path = self.open_fds[pid][fd]
        return self.vfs.read(path, offset, length)

self.open_fds is keyed FIRST by the calling process's own pid, and
only then by the fd number within that process's own table. Since
intruder.pid never called open() at all, self.open_fds has no entry
for intruder.pid whatsoever -- the very first dictionary lookup,
self.open_fds[pid], fails before the fd number is even considered.
The fact that owner_fd happens to be a valid fd NUMBER for owner is
completely irrelevant, because "fd 0" only has meaning relative to
whichever process's own table it's being looked up in.

WHY FD NUMBERS AREN'T SHARED ACROSS PROCESSES
------------------------------
Each process gets its own, independently-numbered sequence of file
descriptors, starting from 0, tracked in self._next_fd[pid]. Two
different processes can easily end up with the identical fd number
(0, 1, 2...) referring to two completely unrelated files, simply
because each one started counting from zero independently. This
mirrors real operating systems directly: a file descriptor is only
ever meaningful as "the Nth thing THIS PROCESS opened," never as a
system-wide identifier -- there's no way to guess or brute-force your
way into someone else's open file just by knowing a small integer,
because the integer alone means nothing without the process context
it belongs to.

WHY THIS WORKS AS AN ANSWER
------------------------------
Deliberately having the intruder use the EXACT SAME fd number the
owner legitimately holds, rather than a random or clearly-invalid
number, makes the isolation claim much stronger -- it rules out "well
of course it failed, that number was never valid for anyone" and
instead confirms the isolation is genuinely per-process, not just
per-number.