Sandboxing allows creating files in the directories of input files

When sandboxing is enabled, an action is currently allowed to create new files in the directories that correspond to input files.

This is probably an accident of how symlink-based sandboxing works: the directories are created in the sandbox location and are never protected. But, for sandboxfs-based sandboxing, this requires extra code and incurs a significant runtime cost due to the need to create directories just in case an action might want to write to them.

I think this is a mistake: treating the location of input files as read-only is generally good practice (imagine building off a source tree on a read-only file system). Thus we should move towards stricter sandboxing. I have an upcoming change to do this in the sandboxfs variant, but we should probably do the same in the symlink variant for consistency reasons.

However, doing this change might break existing builds so it's not trivial to roll out (might need to go through the incompatible changes dance). So far I have encountered a single problem (fixed in f8768306766429bf41ec8a61777beab216c2e62d) though, so the risk is probably low.

The issue names symlink-based sandboxing and sandboxfs-based sandboxing but no files or tests. Start by tracing both sandbox variants and how input-file directories are handled. Done means preventing new files in those directories consistently, while checking for build breakage and whether an incompatible-changes rollout is needed.

Written by the indexing model from the issue text.