Storage emulator authorizes object names with '..' segments as one path but stores them under another (path.join) #11301

[REQUIRED] Environment info

firebase-tools: 15.8.0 (the same code is in 15.34.0, lib/emulator/storage/files.js lines 296-297)

Platform: Windows 11, Node 24

[REQUIRED] Test case

The Storage emulator evaluates security rules against the object name as requested, but stores and reads the bytes under a key built with path.join(bucket, object). path.join collapses . and .. segments, so two different object names that Cloud Storage keeps distinct (object names are literal, dot segments included) end up as one key in the emulator.

With a common ownership rule:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

[REQUIRED] Steps to reproduce

1. Start the Storage and Auth emulators with the rules above.
2. As user B, upload users/B/photo.png.
3. As user A, upload to the object name users/A/../B/photo.png (for example with the Web SDK, uploadBytes(ref(storage, 'users/A/../B/photo.png'), bytes)).
4. As user B, download users/B/photo.png.

[REQUIRED] Expected behavior

Step 3 creates a separate object literally named users/A/../B/photo.png (as Cloud Storage does), and user B's users/B/photo.png is unchanged. Rules decide on the same name that is stored.

[REQUIRED] Actual behavior

The rule matches userId == "A" for step 3, so the write is allowed, but the emulator stores it at users/B/photo.png. Step 4 returns user A's bytes. Reads and deletes behave the same way: a name with .. is authorized as one path and applied to another.

The result is that rules tests run against the emulator can pass or fail for the wrong reason around dot segments, so the emulator is not a reliable check for path rules. Suggested fix: key stored objects by the literal (encoded) object name instead of path.join, or reject object names whose segments are . or .. the same way for both rule evaluation and storage.