I was wondering if it's possible to write a shell script that:
runs chroot for a given userspec and group
monitors/intercepts system calls all processes started, and what libraries they attempt to load, and if the file is not available in the chroot path, but is available in the "normal" system path, instead of failing the access, lets them access the missing file in it's original location outside of the chroot jail, and logs this fact to a log file.
for example, process tries to start /bin/ls, but it's not in the chroot path. a system call hook figures this out, and notices that /bin/ls does exist in the main system /bin path, so this file is cached into the user's chroot and logged.
once the user exits, and the missing files are noted, a script is created that allows the missing files to to be included for the next time the chroot command is used by this user.
the idea is you'd use this to "test" a setup and craft the actual chroot jail that's deployed for normal use, rather than by trial and error.
it has the advantage of (assuming you start with an "empty" jail, knowing precisely what files are known to be needed, and have been provisioned for future use.
i suppose there is no reason why the "live" system couldn't proxy file calls in this way too, however it would need to be well monitored. i suspect it would be very slow due to all the monitoring, so you would not want to run like this long term, but you could have some threshold where a process not needing to proxy files for x number of restarts, would migrate to the non monitored version which would offer the performance increase.
does anything like this exist? if not, what tools would one use to craft such a concept?