[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] [[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU_Free_Documentation_License|/fdl]]."]]"""]] [[meta title="Virtualization Using Hurd Mechanisms"]] The main idea behind the Hurd design is to allow users to replace almost any system functionality ([[extensible_system|extensibility]]). Any user can easily create a subenvironment using some custom [[servers|hurd/translator]] instead of the default system servers. This can be seen as an [[advanced_lightweight_virtualization|hurd/virtualization]] mechanism, which allows implementing all kinds of standard and nonstandard virtualization scenarios. However, though the basic mechanisms are there, currently it's not easy to make use of these possibilities, because we lack tools to automatically launch the desired constellations. The goal is to create a set of powerful tools for managing at least one desirable virtualization scenario. One possible starting point could be the [[hurd/subhurd]]/[[hurd/neighborhurd]] mechanism, which allows a second almost totally independant instance of the Hurd in parallel to the main one. While subhurd allow creating a complete second system instance, with an own set of Hurd servers and [[UNIX]] daemons and all, there are also situations where it is desirable to have a smaller subenvironment, living withing the main system and using most of its facilities -- similar to a chroot environment. A simple way to create such a subenvironment with a single command would be very helpful. It might be possible to implement (perhaps as a prototype) a wrapper using existing tools (chroot and [[hurd/translator/unionfs]]); or it might require more specific tools, like some kind of unionfs-like filesytem proxy that mirrors other parts of the filesystem, but allows overriding individual locations, in conjuction with either chroot or some similar mechanism to create a subenvironment with a different root filesystem. It's also desirable to have a mechanism allowing a user to set up such a custom environment in a way that it will automatically get launched on login -- practically allowing the user to run a customized operating system in his own account. Yet another interesting scenario would be a subenvironment -- using some kind of special filesystem proxy again -- in which the user serves as root, being able to create local sub-users and/or sub-groups. This would allow the user to run "dangerous" applications (webbrowser, chat client etc.) in a confined fashion, allowing it access to only a subset of the user's files and other resources. (This could be done either using a lot of groups for individual resources, and lots of users for individual applications; adding a user to a group would give the corresponding application access to the corresponding resource -- an advanced [[ACL]] mechanism. Or leave out the groups, assigning the resources to users instead, and use the Hurd's ability for a process to have multiple user IDs, to equip individual applications with sets of user IDs giving them access to the necessary resources -- basically a [[capability]] mechanism.) The student will have to pick (at least) one of the described scenarios -- or come up with some other one in a similar spirit -- and implement all the tools (scripts, translators) necessary to make it available to users in an easy-to-use fashion. While the Hurd by default already offers the necessary mechanisms for that, these are not perfect and could be further refined for even better virtualization capabilities. Should need or desire for specific improvements in that regard come up in the course of this project, implementing these improvements can be considered part of the task. Completing this project will require gaining a very good understanding of the Hurd architecture and spirit. Previous experience with other virtualization solutions would be very helpful. Possible mentors: Olaf Buddenhagen (antrik)