71 startup okws is started by a launcher process the

7.1 Startup
OKWS is started by a launcher process. The launcher spawns ok-
demux , site-specific workers requested by the site operator, and two
other processes seen in Figure 1, idd and ok-dbproxy . The processes
8

netd
ok-demux idd Worker W
1. u ’s TCP connection
2. Grant u
C
?
3. Lookup UN/PW
4. Grant u
G
? , u
T
?
5. Grant u
T
?
6. Grant u
C
? , u
G
? ,
Contaminate u
T
3
7. Create W [ u ]
8. Grant
u
W
?
; read/write
Figure 5 : OKWS message flow for handling user u ’s Web request.
exchange and inherit handles to establish the communication paths
seen in the diagram.
The ok-demux must be certain that it is communicating with the
worker processes that the launcher started and wants to avoid trust-
ing workers to identify themselves correctly. Thus, the launcher
grants a process-specific verification handle to each process it
starts. The ok-demux collects these handle values from the launcher.
When a worker identifies itself to the ok-demux , it must provide a
verification label V containing its verification handle at level 0 , al-
lowing the ok-demux to verify that it speaks for the relevant process.
Other designs, such as having the launcher mediate initial commu-
nication with the workers, would also be possible.
In the current prototype, a process crash would necessitate a
restart of the whole process suite, though a more mature version
of launcher could restart dead processes (as in OKWS on Unix).
7.2 Basic connection handling
We now describe the data path of a simple Web request to OKWS
running on Asbestos; Figure 5 shows the steps. When a user u
makes an HTTP connection:
1. The user-level network server netd accepts incoming TCP pack-
ets from the network. Once netd has accepted u ’s connection, it
allocates a new port u
C
to act as a “socket” to which processes
can send READ and WRITE messages. The port label, u
C R
, is
set to { u
C
0 , 2 } , so that no process can initially send to it. Sec-
tion 7.7 describes netd further.
2. As it started up, ok-demux registered with netd to listen for in-
coming TCP connections on the machine’s Web port. Therefore,
netd notifies ok-demux of the new connection by granting it u
C
at level ? .
3. ok-demux reads network data from u over port u
C
until it can
authenticate u . Currently, OKWS uses a simple username and
password pair, though more sophisticated handshakes are pos-
sible. It sends u ’s username and password to OKWS’s identity
server, idd , which is described in Section 7.4.
4. If u provided a valid login, idd grants ok-demux two handles
corresponding to u , a taint handle u
T
and a grant handle u
G
,
both at level ? . These handles function like the similarly-named
handles in Section 5.
5. ok-demux grants u
T
? to netd , which then raises its receive label
to contain u
T
3 and raises u
C R
to { u
C
0 , u
T
3 , 2 } . These changes
allow u
T
-tainted data to escape over the network, but only via
u
C
. From now on, netd will respond to all messages on u
C
(such
as READs) with replies contaminated with u
T
3 .