As development efforts continue, we also want to provide updates on the progress of the 3.0 release. One of the concepts mentioned in our previous post is the concept of plugins. With a few ideas flushed out, we envision that:
1) They are part of the container build time decision, with an option that allows a flag to be set for implementation during runtime. Only system administrators will be able to install plugins, and they must be owned by the root user.
2) Plugins will be called during Singularity runtime. The current thought process is that the plugin will run after container instantiation, but before user payload execution.
3) Plugins will be able to leverage a privilege escalation granted by SUID to do restricted actions. For instance, one could develop a FUSE plugin for Singularity which executes the privileged operations required to mount a file system in user space.
Working in collaboration with CERN’s CVMFS team, we have identified a use case for this particular feature. The scenario is; the plugin will mount CVMFS within the container at runtime, without the necessity of propagating a bind mount from the hosts CVMFS.
We’d really like to hear your feedback on the plans, and learn how plugins might be useful to you. Do you have a particular idea that could become a plugin for Singularity, or comments on the design?
– Reach us on the singularity-container slack channel. Get an invite at the Sylabs website.
– Post to the Google groups discussion forum here.
This continues to be a very exciting time for Singularity and Sylabs. In our next post, we will post an update related to OCI compliance.