Repository navigation
plan9: allow distinct Plan9 share configurations for the same host path - #2939
Conversation
Earlier, Plan9 shares were deduplicated solely by host path, and each share tracked only one guest mount configuration. Reusing a host path with different read-only or file-access settings therefore caused container creation to fail with a configuration mismatch. Allow a host path to own multiple configured shares while continuing to reuse equivalent shares. Within each share, reuse and reference-count matching guest mounts while creating independent mounts for different configurations. Track the exact share and mount selected by each reservation so mapping, cleanup, and retries operate on the correct resources. Use distinct ro/rw guest paths and preserve the filename when mapping a single host file. Identical configurations retain the existing reuse behavior, while releasing one configuration does not affect other active mappings. Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
| // /run/mounts/plan9/<shareName> | ||
| const GuestPathFmt = "/run/mounts/plan9/%s" | ||
| // /run/mounts/plan9/<shareName>-<ConfigKey> | ||
| const GuestPathFmt = "/run/mounts/plan9/%s-%s" |
There was a problem hiding this comment.
Tingmao Wang (@micromaomao) , Takuro Sato (@takuro-sato) does this matter to policy enforcement or tooling?
There was a problem hiding this comment.
Presently, V2 shim does not support confidential containers. But we do want to support it in the future.
As part of that, I think we would need to create pathways for the enforcement of both V1 and V2 paths.
There was a problem hiding this comment.
Tingmao Wang (@micromaomao) , Takuro Sato (@takuro-sato) does this matter to policy enforcement or tooling?
doesn't matter to tooling but gcs does has to allow it, I can take this in the below branch:
As part of that, I think we would need to create pathways for the enforcement of both V1 and V2 paths.
btw, we have a plan in ACI to use the v2 shim for "confidential AI Sandboxes", and in fact allowing v2 paths is implemented in a private branch already - see https://msazure.visualstudio.com/One/_git/Microsoft.hcsshim.ACCfork/commit/c5995540d9b7863cd976db6528105c271b87d3e1?refName=refs/heads/confidential-ai-sandbox
|
Looks good, just want to confirm with Tingmao Wang (@micromaomao) or Takuro Sato (@takuro-sato) that this is ok for enforcer/policy. |
Summary
Earlier, Plan9 shares were deduplicated solely by host path, and each share tracked only one guest mount configuration. Reusing a host path with different read-only or file-access settings therefore caused container creation to fail with a configuration mismatch.
Allow a host path to own multiple configured shares while continuing to reuse equivalent shares. Within each share, reuse and reference-count matching guest mounts while creating independent mounts for different configurations.
Track the exact share and mount selected by each reservation so mapping, cleanup, and retries operate on the correct resources. Use distinct ro/rw guest paths and preserve the filename when mapping a single host file.
Identical configurations retain the existing reuse behavior, while releasing one configuration does not affect other active mappings.
Previous Failure and New Behavior
Before
Two containers in the same LCOW UVM could not mount the same host path with different configurations:
C:\shared→/data(rw)C:\shared→/data(ro)The second request failed with:
Now
The same host path can have multiple configured shares:
roandrw, use separate shares.Testing