Description of the new feature / enhancement
Follow-up from review of #482, which switched the Bubblewrap backend to a deny-by-default filesystem baseline.
With the new baseline, a few situations fail at bwrap exec time with low-level/opaque errors that we can detect beforehand and surface as clear, actionable messages:
working_directory outside the baseline / policy paths — e.g. a cwd of ~/project with no matching readonlyPaths entry. We know the baseline mounts at build time, so we could validate the cwd up front and return an error naming the missing path and the fix (add it to readonlyPaths/readwritePaths).- DNS on hosts where
/etc/resolv.conf symlinks outside the bound /run/... dirs — name resolution silently fails. We could detect the symlink target and either bind it or warn that it needs to be listed in readonlyPaths.
These are not bugs in #482 (the deny-by-default posture is intentional), but better error messages would make the new baseline much easier to adopt.
Proposed technical implementation details
In the Bubblewrap runner, before exec:
- Resolve
working_directory and check it is covered by the baseline or a policy path; if not, return a descriptive MxcError instead of relying on bwrap to fail.
- Optionally resolve the
/etc/resolv.conf symlink target and, if it falls outside the bound DNS dirs, emit a diagnostic so DNS failures are explained.
Description of the new feature / enhancement
Follow-up from review of #482, which switched the Bubblewrap backend to a deny-by-default filesystem baseline.
With the new baseline, a few situations fail at
bwrapexec time with low-level/opaque errors that we can detect beforehand and surface as clear, actionable messages:working_directoryoutside the baseline / policy paths — e.g. acwdof~/projectwith no matchingreadonlyPathsentry. We know the baseline mounts at build time, so we could validate the cwd up front and return an error naming the missing path and the fix (add it toreadonlyPaths/readwritePaths)./etc/resolv.confsymlinks outside the bound/run/...dirs — name resolution silently fails. We could detect the symlink target and either bind it or warn that it needs to be listed inreadonlyPaths.These are not bugs in #482 (the deny-by-default posture is intentional), but better error messages would make the new baseline much easier to adopt.
Proposed technical implementation details
In the Bubblewrap runner, before exec:
working_directoryand check it is covered by the baseline or a policy path; if not, return a descriptiveMxcErrorinstead of relying onbwrapto fail./etc/resolv.confsymlink target and, if it falls outside the bound DNS dirs, emit a diagnostic so DNS failures are explained.