1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
[[!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
independent 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 filesystem proxy that mirrors other parts of the
filesystem, but allows overriding individual locations, in conjunction 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), Carl Fredrik Hammar (cfhammar)
|
