IM-pack: Software Installation Using Disk Images Irena Lanc and Peter Sempolinski

The Problem with Installation Traditional methods of software installation are time-consuming, especially for software with many small files. MS office can take up to 1 hour Most existing packaging systems require a user to be root for installation, un-installation, and updates. This can avoided by downloading and compiling source code, or manually placing bin, usr, lib files. However, these solutions are fiddly and difficult in comparison to package managers.

Idealized Installation Users should be able to install their own software locally for anything not really needing root privileges: Avoid dealing with system administrators Be able to carry a preferred batch of software packages with them from machine to machine Often, user demands on administrators for software produces redundancies

Our Idea Disk images are a potential way of solving these problems. Loop-mounting disk images is much faster than copying files Easier to unmount a disk image than remove files Non-root users can own image files RAM disk images already used in liveCD setups like Knoppix However, many OS components are not designed for this sort of thing.

Our Goal The goal of our project was to quantify the feasibility of such an approach by implementing a basic framework for disk-image software. Will such software, so mounted, work transparently and correctly? What are the current limitations of the OS components needed to build such a system? Of those limitations, which are inherent to the idea and which can be overcome?

The IM-pack System This system involves 3 file locations: 3) 1) 2)

Underlying ext2 filesystem Software components: Virtual File System Image un-installation script Unionfs Image-installation script X X Loop-mounted Device Loop-mounted Device Loop- mounted Device Loop- mounted Device Underlying ext2 filesystem

Usability Our first main metric was qualitative. Can we build a system, using the tools we have now, that is transparent to the user? Recall our last presentation . . .

Install:

Use:

Remove:

Current Limitations Most OS components were not really designed for what we were doing: Component: Issue: Our Workaround: Ideal fix for future work: Unionfs-kernel module Not available in all kernels YES: Ubuntu 9.04 NO: Ubuntu 9.10 HIDDEN limit: about 150 branches Tested performance of both kernel and fuse versions. A final production version configured to run with a Linux distribution Unionfs-fuse Often unwilling to be unmounted. Danger of self-referential file system deadlock. Effectively limited to about 1000 branches Did not mount over top of /usr (Security forbids this as well.) Ideal system would merge functions of Unionfs and loop devices and be only one module. This removes need for many devices and unmounting Loop Devices Limited in kernel to 8 If bypassed, slows virtual machines on boot In 9.10: each device has desktop icon Adjusted GRUB boot flags. Virtual File System Often unaware when devices are no longer busy. Uninstall used backoff and retry when unmounting. Include function to detect what program is locking a filesystem. dpkg – software source Bizarre file corruption causing some packages to mangle file sizes when extracted. Did not use those packages. Images for a production level system would be compiled specifically for it. Ubuntu Update Notifier For some bizarre reason tended to lock all loop devices as busy when appearing. Removed update notifier. Fix that bug in update notifier

Security Limitations Security was the major inherent limit: 1) Our executable had to use both a large number of string buffers and the suid bit. 2) If users allowed to mount images, one could provide an image containing a root shell. Therefore, suid must be disabled on all IM-pack mounts This means NO root level programs allowed 3) Mounting over /usr and similar means one can “replace” files read by root programs. For multiple users, only secure way is to have unioned directory in an alternate location, such as: ~/unionroot/

Performance Metrics Though adding up to 1000 loop devices does slow down the system, it does not render it unusable – it remains functional and responsive. Note: One of us attempted to find every single package that they had ever used which was not part of the core system and barely found 300.

Results: Average Speed of installation: Unionfs-fuse: 11.634 pkg/sec Unionfs-kernel: 1.39 pkg/sec Regular .deb package extraction: 5.1 Mb/sec For smaller packages, the speed is about the same. However, as packages get larger, our system benefits.

Time to Install an image vs. Number of Already Installed Images Time (s) Number of images installed

Time for ls /usr/bin of the union mount vs Time for ls /usr/bin of the union mount vs. Number of Installed Disk Images Time (s) Number of images installed

Time vs. Number of disk images remounted Time (s) Number of images to be remounted

Conclusion Though IM-pack incorporates existing OS system components and tools not designed for our specific goal, it nevertheless exhibits good performance, especially within reasonable usage bounds. The only major limitation is security, but this only means root level components and direct placement on directories expecting root files cannot be done. Other components can optimized to yield greater performance Unionfs Loop devices