<story><title>Binctr: Static, unprivileged, self-contained containers as executable binaries</title><url>https://github.com/genuinetools/binctr</url></story><parent_chain></parent_chain><comment><author>jclarkcom</author><text>I worked on something similar for Windows for nearly 10 years, called Thinstall (acquired by vmware and renamed to Thinapp).   I love the idea of something like that for linux.&lt;p&gt;We put a lot of effort into being able to run an application directly from a compressed single-file binary, you have a small executable with a big payload attached to the end of it.  The payload essentially contains a mountable filesystem, however because windows doesn&amp;#x27;t support doing anything like that from an unprivileged account we had to emulate many things Windows normally does, including execution of binary images.&lt;p&gt;We did some tricks where executable data was stored on disk in a format it can be directly memory mapped and run without reading anything - this allowed us to launch most applications over a network without extracting anything to disk locally and achieve millisecond launch times.  Pages would get pulled into local memory by the OS as needed while the application was running.&lt;p&gt;The end result was that you can create a single EXE file could contain things like python + script, or more complex like photoshop &amp;amp; Word.  Just go to a new computer from a guest account, launch the EXE and you instantly start using that app.&lt;p&gt;I haven&amp;#x27;t been involved with it for the last 6 years, but I believe vmware still offers it.</text></comment>
<story><title>Binctr: Static, unprivileged, self-contained containers as executable binaries</title><url>https://github.com/genuinetools/binctr</url></story><parent_chain></parent_chain><comment><author>mroche</author><text>&amp;gt; Well judging by the original GitHub issue about unprivileged runc containers, the largest group of commenters is from the scientific community who are restricted to not run certain programs as root.&lt;p&gt;Which is why we use Singularity[0]. Apologies if I’m missing something, but to me this problem they’re trying to solve, has already been solved. As stated in the README:&lt;p&gt;&amp;gt; Singularity is an open source container platform designed to be simple, fast, and secure. Singularity is optimized for EPC and HPC workloads, allowing untrusted users to run untrusted containers in a trusted way.&lt;p&gt;Singularity ‘requires’ root or elevated privileges to create and modify containers, but running them is done in the user’s namespace with that user’s permission set. And privileges can’t be elevated during the containers runtime as there are kernel level catches that prevent sudo and su from working inside the container.&lt;p&gt;In terms of the ‘static’ part, Singularity uses SquashFS to produce a single binary image, and uses the SIF (Singularity Image File) format to define applications, their dependencies, and runscripts. On top of being able to run anything inside the container with the `exec` subcommand.&lt;p&gt;You can also create sandbox development images that are just a directory on disk for testing things out and installing&amp;#x2F;building tools manually, then convert it into a SIF container after for cluster deployment. Or be nicer and port your process into a recipe&amp;#x2F;definition file.&lt;p&gt;Most scientific&amp;#x2F;HPC related centers have started utilizing Singularity for their container workflow. Tools like 
Docker are essentially banned because of their perma-root privileges[1].&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;sylabs&amp;#x2F;singularity&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;sylabs&amp;#x2F;singularity&lt;/a&gt;
[1] I’m an admin who reimplemented Singularity on our university’s cluster. With a heavy need on filesystem integration (which Singularity solves with great configuration options), containers which run with root privileges would be a massive security vulnerability.</text></comment>