Lately we’re working on tools that interact with a users existing ROS installation on 16.04 / 18.04. Mainly looking for ways to read & execute files located in the host system /opt/ros/* and not seeing a clear solution. I’ve tried at the system-files interface:
I’m not sure there’s a particularly good way to do this without classic confinement. If you’re truly wanting to be able to run random executables within /opt/ros/, you need access to more than just /opt/ros/. You need access to every library/dependency used by any executable you’re trying to run, and they’re all going to be covered under the confinement profile of whatever snapped app you’re using to run them. Confined snaps just don’t have that type of access to the host, and building up a set of system-files interfaces that would cover such a use-case would seem to me to be just as unsafe as classic confinement. @jdstrand may have some thoughts here.
Beyond that more hypothetical issue, onto practicalities: remember that strictly-confined snaps run with a base snap (typically either core or core18) as their execution context (their rootfs, for the most part). The core snap doesn’t contain /opt/ros/, so the confined snap won’t see it either. The host’s rootfs is actually found in /var/lib/snapd/hostfs/ from within the snap’s execution environment, and isn’t typically accessible under strict confinement. You might try that in the system-files interface, but that’s ignoring the issues I outlined above.
IME this needs to be classic. Sidestepping the fact that /opt isn’t in the snap’s runtime, while we could theoretically limit the commands to be run to those down in /opt/ros, we can’t limit what those commands can run, as @kyrofa mentioned. This isn’t terribly different from the IDE cases which need classic confinement.
Thanks for the replies. Just wanted to make sure we exhaust every avenue to be more confined before heading down the classic road. Our use case is ultimately very similar to IDEs and CI/CD software.
