blob: 593347f7588194e339f4678ec6b90ab3cc2cfa97 (
plain)
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
|
== Problem: Define the uid reservation lifecycle == #none
Situation:
Several processes are engaged in uid reservation, use, or collection. A
precise description of the life-cycle for uids will help avoid race
conditions between these processes.
Thoughts:
A state-cell is created in the 'launching_<pid>' state.
(uid is known, but not yet in use.)
The reservation is atomically symlinked to the pre-initialized state-cell.
This way, the reservation always starts off in a consistent state.
Perhaps, the launch succeeds in dropping privileges:
- The reservation can be now be marked 'launch_succeeded'.
- 'launch_succeeded' uids can be collected whenever there are no processes
running under 'uid'.
- However, because permissions were dropped, some other process will need
to update the state-cell.
Perhaps, the launch fails to drop privileges and exits abnormally or diverges:
- Since divergence will be rare, we can speed things up by marking the
reservations of known-failed launches as 'launch_failed'.
- 'launch_failed' uids can be collected at any time.
- Divergent uids will be halted by reboots and their reservations can be
collected at system startup.
From time to time, a gc step examines reservations.
Reservations for '<uid>' marked as 'launching_<pid>' should be collected if
<pid> is no longer running.
- (How do we handle reboot detection?)
Reservations marked as 'launch_succeeded' should be collected
marked 'launch_succeeded', 'launch_failed':
the gc process may decide to claim the reservation by marking it
'gcing_<pid>'
gc succeeds: reservation is deleted.
gc fails: the reservation will never be touched by rainbow-daemon again. (other
collection tools might be applied, but only under controlled
circumstances)
|
