Allow mapping a host file source to a different destination path in the sandbox #1366

Description of the new feature / enhancement

Allow a filesystem policy to map a host source file to a different destination path inside the sandbox.

Today a policy can grant a path read-only or read-write access, or deny it. It cannot make the sandboxed process see a different file at a given path. Some callers need to give a process a file at the path where a tool expects it, with content prepared by the caller, without modifying the file on the host.

Example: a caller prepares /run/user/1000/app/config.prepared and wants the sandboxed process to see it as ~/.config/tool/config, while the real ~/.config/tool/config stays untouched on the host.

Proposed technical implementation details

A minimal shape could be a list of read-only mappings in the filesystem policy:

"filesystem": {
  "mappedPaths": [
    { "source": "/path/on/host", "destination": "/path/in/sandbox" }
  ]
}

Possible semantics:

• Read-only mappings first; read-write could come later if needed.
• The mapping takes precedence over other grants and denials for the destination path.
• The source must exist when the sandbox starts; the destination may or may not exist on the host.
• Expose it as a backend capability, so callers can detect support and fall back (for example, to denying the destination) where it is not available.

Backend notes:

• Bubblewrap / LXC: a bind mount of the source onto the destination. Bubblewrap already does this internally (/dev/null over denied files, the /etc/hosts pin).
• Windows: unsure what is feasible for process containers; input from maintainers welcome.
• Seatbelt: probably not possible, since SBPL can only allow or deny access by path. The capability would be absent there.