Fix Projector Plugin vulnerability

[psamanoelton]

Summary

Fixes an arbitrary file read issue in the TensorBoard Projector plugin by restricting asset paths to the directory that contains projector_config.pbtxt.

Previously, user-controlled fields such as metadata_path, tensor_path, bookmarks_path, and sprite.image_path could resolve to absolute paths or traversal paths outside the intended logdir/config directory. That allowed a malicious config to make TensorBoard read and return arbitrary local files from the host.

What Changed

• Hardened projector asset path resolution to:
  • expand and normalize candidate paths
  • resolve them against the directory containing projector_config.pbtxt
  • reject any path that escapes that directory boundary
• Returned a clean 400 response when a requested asset path is invalid
• Applied this validation consistently across:
  • metadata loading
  • tensor loading
  • bookmarks loading
  • sprite image loading
• Updated config augmentation logic to safely skip invalid external tensor paths instead of trying to read them

Security Impact

This closes a path traversal / arbitrary local file read vector in the Projector plugin for deployments where an attacker can write or influence projector_config.pbtxt contents under a scanned logdir.

Tests

Added projector integration coverage for:

• metadata_path using traversal outside the logdir
• tensor_path using an absolute path outside the logdir
• bookmarks_path using an absolute path outside the logdir
• sprite.image_path using traversal outside the logdir

Validation

Verified:

• python -m py_compile tensorboard/plugins/projector/projector_plugin.py tensorboard/plugins/projector/projector_plugin_test.py
• bazel test //tensorboard/plugins/projector:projector_plugin_test
• Full build and test suite

Risk / Compatibility

Low risk for valid configurations.

This change may reject projector configs that previously referenced assets outside the config directory, but that behavior is now considered unsafe and is intentionally blocked.

[arcra]

Are there other possible ValueErrors that are expected besides the one we're raising? This seems a bit odd to me. Let's just raise the error with the proper error message directly?

[psamanoelton]

Updated this.

I changed it so we only catch ValueError from os.path.commonpath(...) itself and otherwise raise the final error message directly when the resolved path is outside the config directory.

Thanks!

[arcra]

These tests might be clearer and less error-prone if we use hard-coded, readable values, instead of relying on logic, e.g. /home/my_username/log_dir/ and /home/my_username/restricted_dir/

[psamanoelton]

Updated this.

I rewrote the setup to use explicit log_dir and restricted_dir directories and hard-coded readable traversal paths like ../restricted_dir/outside_metadata.tsv, so the boundary being tested is clearer.

Thanks!