fix(io-isolated-storage): confine IsolatedStorageFileStream to its store (#2208)

The constructor took a std::filesystem::path and checked nothing: it opened
whatever it was handed, anywhere on the filesystem, and created that path's
missing parent directories on the way. That is a WIDER hole than the TOCTOU
#2207 declared and accepted -- that race needs an attacker who can already
write inside the store root plus a window between check and use; this needed
neither a race nor a privilege, only the call. It was the one door on a type
that exists to confine file access which confined nothing.

THE REFERENCE CORRECTED THIS TICKET'S PROPOSED SHAPE, and the correction
removed the source break it was priced around. #2208 said "remove the path
constructor and take the owning store instead". .NET publishes eight
constructors, all beginning (string path, FileMode mode, ...), with the store
an OPTIONAL TRAILING parameter (IsolatedStorageFileStream.cs:21-56); its
storeless form is NOT unconfined -- a null store means GetUserStoreForDomain(),
resolved through isf.GetFullPath(path) exactly as the store-taking form is
(:82-118). So the confinement lands without removing an overload .NET
publishes and without inventing a leading-store parameter order. The
(store, path, mode) order an earlier cut used is now pinned as not compiling,
because the wrong order compiles perfectly well as an addition and no
behavioural test can see it -- both orders confine correctly.

On POSIX there is no source break at all: std::filesystem::path converts to
std::string implicitly, so an existing call still compiles and only its
MEANING moves, from "this filesystem path" to "this path inside the store".
On Windows value_type is wchar_t and the spelling breaks.

An absolute path is CONTAINED, not refused -- fullPath() strips leading
separators at every door (#2209's rule), and refusing it here alone would make
the type inconsistent with itself.

Also landed:
  * mode validation with .NET's own text, before the file is created;
  * IsolatedStorageFile::GetUserStoreForDomain(), purely additive, .NET's
    exact scope combination -- the store the storeless form defaults to;
  * a private four-argument constructor so each door reports its OWN parameter
    name (#2323's rule): `path` from the constructors, `relativePath` from
    OpenFile/CreateFile.

.NET's `path == "\\"` check is deliberately not reproduced: on POSIX a
backslash is an ordinary file-name character, as this module's own
isDirectorySeparator() says. The outcome is identical anyway.

Eight mutations, seven caught, one a proven equivalence (the default store's
scope is unobservable -- both factories call the same GetIsolatedStorageRoot()
and the stream never retains the store). Three were invalid as first written
and were reformulated rather than counted. Seven of the eight are caught by
PRE-EXISTING confinement tests, which is the point: OpenFile now routes
through the constructor. The one only the new cases catch is the half-repair.

Gate: 17,590 run / 17,590 passed / 0 failed / 0 skipped across 38 executables,
recounted from the per-executable logs (+1, IO_IsolatedStorage 62 -> 63).
Negative fixture set 46/236 -> 47/240, measured by the checker.
Downstream: zero constructions in cna and mobile-eggbert.
Build: build/ only, --parallel 2 throughout.

Author: robertvokac

CLAUDE.md

@@ -0,0 +1,131 @@
+<!-- SPDX-License-Identifier: MIT -->
+<!-- Copyright (c) Robert Vokac and contributors -->
+
+# Migration: `IsolatedStorageFileStream` is confined to its store (#2208)
+
+**Landed:** 2026-08-19, branch `next`. **Ticket:** #2208.
+
+## What changed
+
+`System::IO::IsolatedStorage::IsolatedStorageFileStream`'s public constructor was
+
+```cpp
+IsolatedStorageFileStream(const std::filesystem::path& fullPath, System::IO::FileMode mode);
+```
+
+It opened whatever path it was handed, **anywhere on the filesystem**, and created that path's
+missing parent directories on the way. It is now
+
+```cpp
+IsolatedStorageFileStream(const std::string& path, System::IO::FileMode mode);
+IsolatedStorageFileStream(const std::string& path, System::IO::FileMode mode,
+                          const IsolatedStorageFile& store);
+```
+
+Both forms resolve `path` against a store's root through that store's own `fullPath()` — the same
+resolver `OpenFile`, `CreateFile`, `DeleteFile` and `MoveFile` already used — so a path that
+escapes the store is refused **before any filesystem access happens**.
+
+## Why this is more than a tidy-up
+
+The type exists to confine file access, and this was the one door on it that confined nothing.
+It was a **wider hole than the TOCTOU #2207 declared and accepted**: that race needs an attacker
+who can already write inside the store root, and a window between check and use. This needed
+neither a race nor a privilege — only the call.
+
+## The reference corrected this ticket's proposed shape
+
+#2208 was written as *"remove the path constructor and take the owning store instead"*, and that
+is **not** what .NET does. .NET publishes **eight** constructors and every one begins
+`(string path, FileMode mode, ...)` with the store as an **optional trailing** parameter,
+`IsolatedStorageFile? isf` (`IsolatedStorageFileStream.cs:21-56`).
+
+Its storeless form is **not unconfined**. When `isf` is null it takes
+`IsolatedStorageFile.GetUserStoreForDomain()` and then resolves through `isf.GetFullPath(path)`
+exactly as the store-taking form does (`:82-118`). So the confinement this ticket exists to add
+is obtained **without removing an overload .NET publishes** and without inventing a leading-store
+parameter order.
+
+That correction removed the source break the ticket was priced around. An earlier cut of this
+work used `(store, path, mode)`; it is now pinned as **not compiling**, because the wrong order
+would compile perfectly well as an *addition* and would leave this port with two spellings where
+.NET has one.
+
+## Is this a source break?
+
+**On POSIX, essentially no.** `std::filesystem::path` converts to `std::string` implicitly there
+(`path::operator string_type()`, and `value_type` is `char`), so an existing
+`IsolatedStorageFileStream(somePath, FileMode::Open)` still compiles.
+
+**Its meaning changes**, and that is the repair rather than a side effect: the argument used to be
+a filesystem path and is now a path relative to the store. An absolute path is **contained, not
+refused** — `fullPath()` strips leading separators at every door, so `"/etc/passwd"` now names
+`<store-root>/etc/passwd`. That rule is older than this ticket (#2209 recorded it) and refusing it
+at this one door alone would make the type inconsistent with itself.
+
+**On Windows it is a source break**, because `std::filesystem::path::value_type` is `wchar_t`
+there and no implicit conversion to `std::string` exists. Callers pass `p.string()`.
+
+## Migration
+
+Measured on 2026-08-19:
+
+| Consumer | Constructions | Note |
+|---|---|---|
+| `cna` | 0 | no occurrence of the type at all |
+| `mobile-eggbert` | 0 | one `#include` in `WindowsPhoneSpeedyBlupi/Worlds.cpp:60`, no construction |
+| first-party | 1 | `IsolatedStorageFile::OpenFile`, which already held the store it now passes |
+
+So the migration is **empty**. Where a call does exist:
+
+```cpp
+// before
+IsolatedStorageFileStream s(store.getRootDirectoryProperty() / "save.dat", FileMode::Create);
+// after -- the store resolves the path
+IsolatedStorageFileStream s("save.dat", FileMode::Create, store);
+```
+
+## Two behaviours that came with it
+
+- **The mode is validated.** A `FileMode` outside the six defined values is rejected with .NET's
+  own text, `Invalid mode, see System.IO.FileMode.` (`SR.IsolatedStorage_FileOpenMode`), before
+  the file is created. Every named `FileMode` is legal, so only a value cast in from outside the
+  enumeration can reach it.
+- **Each door reports its own parameter name.** The public constructors name `path`; `OpenFile`
+  and `CreateFile` still name `relativePath`, which is what their own parameters are called.
+  Routing every door through one resolver made it possible for one door's diagnostic to name
+  another's parameter, which is the shape #2323 rules out.
+
+## What .NET's check this port does not reproduce
+
+.NET additionally rejects a path equal to `"\\"` (`SR.IsolatedStorage_Path`). On POSIX a backslash
+is an ordinary file-name character — this module's own `isDirectorySeparator()` says so in a
+comment — so reproducing that literal test would reject a legitimate name. The outcome is
+nonetheless the same on both platforms: `fullPath()` strips leading separators and rejects what is
+left when it is empty, which covers `"/"` on POSIX and both `"/"` and `"\\"` on Windows.
+
+## New public member
+
+`IsolatedStorageFile::GetUserStoreForDomain()` was added, purely additively, because it is the
+store .NET's storeless constructor defaults to. It uses .NET's exact scope combination
+(`Assembly | Domain | User`, `IsolatedStorageFile.cs:466-469`). Like this port's other two
+factories it resolves to the same storage root, so the scope is **recorded rather than reflected
+in the directory** — which is why a mutation swapping it for `GetUserStoreForApplication()` is an
+unobservable equivalence here. It is written as `ForDomain` for fidelity to the reference, not
+because anything in this port can tell the difference.
+
+## Evidence
+
+Eight mutations, seven caught, one a proven equivalence (the store scope, above). Three were
+invalid as first written — `-Werror=unused-parameter`, `-Werror=unused-function`, and a
+`[[nodiscard]]` on `fullPath()` — and were reformulated rather than counted. The mutation that
+only the new cases catch is the **half-repair**: `OpenFile` pre-resolving while the constructor
+ignores its store, which leaves the direct door open while every pre-existing confinement test
+still passes.
+
+The other seven are caught by **pre-existing** confinement tests, which is the point: `OpenFile`
+now routes through the constructor, so the whole shipped confinement suite covers it.
+
+Negative consumer fixture: `test/consumer/io_isolated_storage_stream_confinement_negative.cpp`,
+four sites — the store's private `fullPath()`, the private resolving constructor, the private
+`Resolve()`, and the store-first parameter order that .NET does not have.

a/b/c/leaf.dat

@@ -1555,7 +1555,7 @@ sanitizer was given a deliberate defect built with the same flags:
 
 §21.5 records **11 fixtures / 94 sites**, and that has been stale since 2026-08-04: the measured
 total today is **45 fixtures / 231 sites**. #1894 adds no fixture of its own, so the total is
-unchanged by this section.
+unchanged by this section. (§23 later takes it to **47 fixtures / 240 sites**.)
 
 **The first version of this subsection claimed the intervening fixtures "were each recorded in
 their own ticket's migration note rather than here, so the record exists". That was asserted rather
@@ -1601,3 +1601,44 @@ the audit re-runs clean: **0 fixtures without a `docs/` record.**
 
 Build directories used: `build-asan` (reused) and `build-ubsan` (created), both `--parallel 2`,
 both with `ccache`.
+
+---
+
+## 23. Ticket #2208 — the isolated-storage stream confinement fixture (2026-08-19)
+
+`test/consumer/io_isolated_storage_stream_confinement_negative.cpp`, **4 sites**, component
+`IO.IsolatedStorage`. Running total: **47 fixtures / 240 sites**, measured by running
+`scripts/check_negative_consumer_fixtures.py` rather than derived from §22.4 -- whose 45/231 was
+itself already stale, #1888/#1889 having taken it to 46/236 earlier the same day.
+
+### 23.1 What is unusual about this one
+
+Almost every fixture in this document pins a **spelling a ticket outlawed**. This one pins
+almost none, and the reason is a premise correction worth recording.
+
+#2208 was written as *"remove `IsolatedStorageFileStream`'s path constructor and take the owning
+store instead"*, which would have been a public source break with an outlawed spelling to pin.
+The reference says otherwise: .NET publishes eight constructors, all beginning
+`(string path, FileMode mode, ...)`, with the store an **optional trailing** parameter
+(`IsolatedStorageFileStream.cs:21-56`); its storeless form defaults to
+`GetUserStoreForDomain()` and resolves through `isf.GetFullPath(path)` like every other
+(`:82-118`). So the confinement landed **without removing an overload**, and on POSIX there is
+no source break at all — `std::filesystem::path` converts to `std::string` implicitly there, so
+the old call still compiles and only its *meaning* changes.
+
+What is left to pin is therefore not a spelling but a **structure**: the ways a consumer could
+step around the resolver.
+
+### 23.2 The four sites
+
+| # | id | what it proves |
+|---|---|---|
+| 1 | `store-fullpath-is-not-consumer-reachable` | `IsolatedStorageFile::fullPath()` is private and the stream is its only friend, so the friendship the repair relies on grants a consumer nothing |
+| 2 | `resolving-ctor-is-private` | the four-argument constructor — the only one taking its `paramName` from the caller rather than from the door — is unreachable |
+| 3 | `resolve-is-private` | `Resolve()` is private, so nothing advertises that the check is separable from the construction |
+| 4 | `store-first-overload-does-not-exist` | the `(store, path, mode)` order .NET does not have |
+
+**Site 4 is the one this section exists for.** An earlier cut of #2208 used exactly that order,
+before the reference was read. The wrong order is not a compile error waiting to happen — it
+compiles perfectly well as an *addition*, and would leave this port with two spellings where
+.NET has one. A behavioural test cannot see it, because both orders confine correctly.

dirlink/written.dat

@@ -61,6 +61,10 @@ namespace System::IO::IsolatedStorage
     class IsolatedStorageFile : public IsolatedStorage
     {
     private:
+        /// #2208: the stream resolves its relative path through this class's own fullPath(), so
+        /// the confinement has exactly one implementation rather than two that could drift.
+        friend class IsolatedStorageFileStream;
+
         std::filesystem::path rootDirectory_; ///< Root directory of this isolated storage scope.
         bool disposed_ = false;               ///< True after Close()/Dispose().
 
@@ -127,6 +131,16 @@ namespace System::IO::IsolatedStorage
         /** Returns an isolated storage scoped to the current assembly (same root as application). */
         [[nodiscard]] static IsolatedStorageFile GetUserStoreForAssembly();
 
+        /**
+         * @brief Obtains the user store scoped to the calling assembly and domain.
+         *
+         * .NET's `GetStore(Assembly | Domain | User)` (IsolatedStorageFile.cs:466-469). It is the
+         * store `IsolatedStorageFileStream`'s storeless constructor defaults to, which is why
+         * #2208 needed it; like this port's other two factories it resolves to the same storage
+         * root, so the scope is recorded rather than reflected in the directory.
+         */
+        [[nodiscard]] static IsolatedStorageFile GetUserStoreForDomain();
+
         // --- File operations ---
 
         /** Returns true if the specified relative path exists as a file in isolated storage. */

docs/Migration-IsolatedStorageStreamConfinement.md

@@ -4,18 +4,45 @@
 #pragma once
 
 #include <filesystem>
+#include <string>
 
 #include "System/IO/FileMode.hpp"
 #include "System/IO/FileStream.hpp"
 
 namespace System::IO::IsolatedStorage
 {
+    class IsolatedStorageFile;
+
     /**
      * @brief Represents a file stream inside isolated storage.
      *
      * C++ counterpart of .NET System.IO.IsolatedStorage.IsolatedStorageFileStream, which
      * derives from FileStream; this port does the same, inheriting Read/Write/Position/
-     * Seek/CanSeek/SetLength. Obtain instances via IsolatedStorageFile::OpenFile()/CreateFile().
+     * Seek/CanSeek/SetLength.
+     *
+     * @note **Confined since ticket #2208 (2026-08-19).** The constructor used to take a
+     * `std::filesystem::path` and check nothing: it opened whatever it was handed, anywhere on
+     * the filesystem, and created that path's missing parent directories. That was a **wider
+     * hole than #2207's declared TOCTOU** -- no race and no privilege were needed, just the call.
+     *
+     * **The reference corrected this ticket's proposed shape.** #2208 was written as "remove the
+     * path constructor and take the owning store instead", but .NET publishes eight constructors
+     * and every one of them begins `(string path, FileMode mode, ...)` with the store as an
+     * **optional trailing** parameter (`IsolatedStorageFile? isf`,
+     * `IsolatedStorageFileStream.cs:21-56`). Its storeless form is **not** unconfined: when `isf`
+     * is null it takes `IsolatedStorageFile.GetUserStoreForDomain()` and resolves through
+     * `isf.GetFullPath(path)` exactly as the store-taking form does (`:82-118`). So the
+     * confinement this ticket exists to add is obtained **without** removing an overload .NET
+     * publishes and without inventing a leading-store parameter order.
+     *
+     * Both forms therefore resolve `path` against a store's root through the same `fullPath()`
+     * every other door on `IsolatedStorageFile` uses; a path that escapes is refused before any
+     * filesystem access happens.
+     *
+     * The parameter type changed with the meaning: `std::filesystem::path` -> `std::string`,
+     * which is .NET's. On POSIX `std::filesystem::path` converts to `std::string` implicitly, so
+     * an existing call still compiles and its **meaning** changes -- from "open this filesystem
+     * path" to "open this path inside the store". That is the repair, not a side effect.
      */
     class IsolatedStorageFileStream : public System::IO::FileStream
     {
@@ -34,9 +61,61 @@ namespace System::IO::IsolatedStorage
          *          as a parameter, a public signature change tracked as ticket #2208.  Prefer
          *          IsolatedStorageFile::OpenFile()/CreateFile().
          */
-        IsolatedStorageFileStream(const std::filesystem::path& fullPath, System::IO::FileMode mode);
+        /**
+         * @brief Opens a stream on @p path inside the default user store.
+         * @param path Path relative to the store. Leading separators are stripped, as at every
+         *             other door, so an absolute path is contained rather than refused.
+         * @param mode How the file should be opened or created.
+         * @throws System::ArgumentException if @p path would resolve outside the store, is empty,
+         *         or @p mode is not one of the six defined FileMode values.
+         *
+         * The .NET counterpart defaults to `IsolatedStorageFile.GetUserStoreForDomain()` and this
+         * port does the same.
+         */
+        IsolatedStorageFileStream(const std::string& path, System::IO::FileMode mode);
+
+        /**
+         * @brief Opens a stream on @p path inside @p store.
+         * @param path  Path relative to @p store.
+         * @param mode  How the file should be opened or created.
+         * @param store The owning isolated store; the path is resolved against its root.
+         * @throws System::ArgumentException as above.
+         *
+         * The store is trailing because .NET's is (`IsolatedStorageFileStream.cs:26`). It is a
+         * reference rather than .NET's nullable `IsolatedStorageFile?` because passing null there
+         * is defined to mean "use the default store", which is what the two-argument overload
+         * above already spells.
+         */
+        IsolatedStorageFileStream(const std::string& path,
+                                  System::IO::FileMode mode,
+                                  const IsolatedStorageFile& store);
 
         /** Closes the underlying file stream, syncing IDBFS on Emscripten builds. */
         void Close() override;
+
+    private:
+        friend class IsolatedStorageFile;
+
+        /**
+         * The resolving constructor every public one funnels through. @p paramName is the name
+         * the CALLING door gives its own path parameter, so a refusal names the parameter the
+         * caller actually wrote: `path` from the two public constructors, `relativePath` from
+         * IsolatedStorageFile::OpenFile()/CreateFile(). Reporting one door's parameter name from
+         * another door is the shape #2323 rules out.
+         */
+        IsolatedStorageFileStream(const std::string& path,
+                                  System::IO::FileMode mode,
+                                  const IsolatedStorageFile& store,
+                                  const char* paramName);
+
+        /**
+         * Validates @p mode, resolves @p path through @p store's own confinement check, and
+         * creates the file's missing parents. A member rather than a free function because
+         * IsolatedStorageFile::fullPath() is private and this class is its only friend.
+         */
+        [[nodiscard]] static std::string Resolve(const std::string& path,
+                                                 System::IO::FileMode mode,
+                                                 const IsolatedStorageFile& store,
+                                                 const char* paramName);
     };
 }