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
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
[[!meta copyright="Copyright © 2011, 2012 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]]."]]"""]]
[[!tag open_issue_documentation open_issue_hurd]]
# IRC, freenode, #hurd, 2011-08-10
< braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ?
< youpi> no idea
< braunr> i also don't understand the recursive property
< youpi> a user can run a subhurd
< neal> braunr: What don't you understand?
< youpi> a user in a subhurd can run a subhurd
< youpi> etc
< braunr> i'm not sure it's really recursive
< neal> youpi: At some point it was observed that you don't strictly
require any resources from the "parent" Hurd.
< neal> youpi: i.e., you could have two Hurds running "directly" on Mach
< youpi> sure
< neal> youpi: Hence neighbor rather than sub
< youpi> but you need to be root for that
< youpi> or else your subhurd can't do much
< neal> you need to have been authorized to use the required resouces
< youpi> which is about the same :)
< neal> depends how they are delegated
< youpi> that's still asking root for something
< neal> if you say so
< youpi> which is most probably not the default
< braunr> well, either you depend on the parent to do things on your
behalf, or you directly have some privileged ports
< braunr> i'd agree with youpi that it's pretty much having root access at
some point
< youpi> and usually you don't have privileged ports by default :)
< braunr> but we don't need to restrict the presentation to user only sub
hurds
< braunr> people don't mind switching to root on their desktops
< braunr> which is one of the reasons they ask "what does the hurd really
bring me today ?"
< braunr> but being able to run truely separate hurds or recursive hurds is
something nice most OSes can't do easily
< youpi> switching to root becomes a *pain* when you have to do it 1 every
two commands
< braunr> yes sure, but some people might just say you're clumsy :x
< neal> The question is: can I start a sub-hurd from within another hurd
that survives the parent's hurd exiting? The answer is yes. The reason
is that the sub-hurd can be constructed in such a way that it does not
rely on the parent. In this case, the parent does not necessarily
subjugate the sub-hurd. Hence the name.
< braunr> but that's out of the scope of the discussion
< antrik> using the traditional, root only mechanism, neighbour-hurd is
indeed a more appropriate term. apart from the initial terminal being
proxied to the parent system by the boot program, they are really equal
< antrik> with zhengda's work on non-root subhurds, you rely on various
proxies in the parent system to access privileged resources; so subhurd
is indeed a more appropriate term in this case
< antrik> (not only non-root subhurds in fact... when using any of the
proxies, such as the network multiplexer -- even if still running as
root...)
< youpi> antrik: you could still give a com0 port as terminal
< antrik> I don't think that's actually supported in the boot
program... but it doesn't really matter, as you don't really need the
terminal anyways -- you can always log in through the network
# IRC, freenode, #hurd, 2012-07-31
<gg0> subhurd seems like bsd jail (tried none of them)
<antrik> gg0: nope. BSD jails are mostly chroot AIUI. subhurd is quite
different
<antrik> gg0: you actually boot a completely new system instance
<antrik> complete with all the Hurd servers, UNIX daemons etc.
<braunr> jails are between subhhurds and chroots :p
<braunr> i suppose there is nothing against making the root server of the
subhurd use a file instead of a raw disk, is there ?
<gg0> well, I said jails cos afaik are more isolated from real system than
chroots
<braunr> yes
<gg0> maybe comparing subhurd to virtual machines would be more
appropriated then
<braunr> they're not VMs either
<gg0> say chroot -> jail -> subhurd -> vm ?
<braunr> unless you consider the microkernel to be a hypervisor, with its
own architecture, which some actually do
<braunr> gg0: something like that, yes
<gg0> [system-in-system evolution]
<braunr> a subhurd is an operating system instance
<braunr> i think the closest analogy you can get is openvz
<antrik> yeah, I'd also consider it closest. but it's still quite
different: with OpenVZ, the kernel facilities are only logically
isolated; but they use the same kernel code. with subhurds, most of the
system facilities are independent
# IRC, freenode, #hurd, 2012-08-03
<antrik> hm... are Mach task IDs exposed to userspace?
<braunr> antrik: ids ?
<braunr> antrik: what do you call a mach task id ?
<antrik> task have numeric IDs in the kernel
<antrik> I wonder whether these are ever exposed to userspace
<braunr> i'm not sure
<braunr> i don't remember the had numeric IDs
<braunr> they*
<antrik> well, perhaps I'm making things up... but I believe I saw such IDs
in the debugger and/or in error messages
<braunr> probably their address
<braunr> or creation time orpc_sample
<antrik> braunr: well, any unique ID would do
<braunr> antrik: yes but i was wondering what kdb would actually show
<antrik> I just realised that it would be useful for debugging accross
subhurds or kernel/userspace if some kind of unique task IDs could be
shown in ps output
<braunr> yes
<braunr> this requires some thought though
<braunr> ps shouldn't show that
<braunr> there should be mach specific commands i suppose
<braunr> but then, gdb and other tools wouldn't have access to subhurd
tasks either
<antrik> why shouldn't ps show that? I don't think it's any more sensitive
information than all the other stuff ps shows...
<braunr> it doesn't feel right
<braunr> i would want my system instances to be truely isolated
<braunr> and use special "cross instance" facilities
<braunr> when necessary
<antrik> that's completely orthogonal to what I'm talking about
<braunr> like eth-multiplexer
<braunr> you seem to be talking about security
<braunr> or privacy
<antrik> we discussed such options when zhengda worked on rootless subhurd
<antrik> no, I'm talking about convenient debugging
<braunr> right
<braunr> i don't think it'zs orthogonal here
<braunr> if we increase separation, it becomes less convenient
<antrik> for debugging purposes you would *not* use the isolation options
<braunr> ok so you propose two modes of operations
<antrik> BTW, as an isolated subhurd relies on the parent, it makes no
sense to hide subhurd tasks from the parent hurd -- only hide parent hurd
task from the subhurd
<braunr> agreed
<antrik> so even with an isolated subhurd global task IDs would still be
useful
# IRC, freenode, #hurd, 2012-08-06
<braunr> antrik: if i'm right, the root file system executable is read from
the parent, right ?
<antrik> braunr: probably... I'm not sure about that part
<braunr> antrik: i've installed the same packages in both the main and
subhurds to be sure
<braunr> and to have the right binary and debugging symbols in gdb anyway
|
