By preserving all capabilities granted in the parent user namespace for the child process, we successfully utilize fuse-overlayfs (fusermount) to perform overlay mounts. This enhancement is effective when using containerexec and runexec, as benchexec creates containers using unshare rather than cloning a new process. Support for benchexec is currently under development.

By setting up the container's filesystem in the child process, bind mount-related errors in benchexec caused by fuse-overlayfs can be avoided. This change will not affect the normal operation of kernel overlayfs.

…ants in libc.py

The cap_permitted_to_ambient function was not handling the case where the "/proc/sys/kernel/cap_last_cap" file could not be read. This commit fixes the bug by adding a fallback value of 0 when reading the file fails.

…ed usage of kernel and FUSE overlayfs.

…ents, and made some logical refactoring.

…nd add comments.

…prove comments

…prove comments

…nested containers.

…fs subprocess to avoid pytest failures, along with some code changes.

…verify the existence of /dev/fuse when running inside a container, and optimize error handling.

…f the path being overlaid and add a check before modifying TEST_TOKEN.

…bility

…xecutorWithContainer

The temp_base directory (.../temp) is the one that BenchExec uses
to store output files of the tool, and after a run we iterate through it
and copy files from there to the output directory.
Thus we should not use it for internal stuff.
But the work_base directory is fine for that.
So let's move the fuse mountpoint to work_base as well.

Somehow this causes deadlocks that we did not manage to solve
even by making our own temp directory hidden.
So let's at least avoid the deadlock and provide a proper error message.
More background is in the discussions:
#1062 (comment)
#1062 (comment)