1 |
Hello, fellow developers. |
2 |
|
3 |
I've added a few new fancy features for Gentoo developers to portage |
4 |
git. Sadly, since Zac isn't planning another release until 2.2.0 goes |
5 |
stable, you need to switch to -9999 to use them. But I say to you, it's |
6 |
worth the hassle. |
7 |
|
8 |
The features are off by default since they need proper testing and can |
9 |
break a lot of ebuilds. And FEATURES=network-sandbox does. |
10 |
|
11 |
It should be noted that all of the features follow the systemd idea of |
12 |
supporting Linux only and require fancy kernel features. |
13 |
|
14 |
|
15 |
The following new FEATURES have been added: |
16 |
|
17 |
1. FEATURES=cgroup |
18 |
|
19 |
Requires: CONFIG_CGROUPS |
20 |
|
21 |
Applies to: all src_* phases |
22 |
|
23 |
Enables long-awaited cgroup support in portage. Each ebuild is confined |
24 |
within a control group and all spawned processes are tracked. Once |
25 |
the phase exits, all remaining orphans are killed. |
26 |
|
27 |
This helps especially with multiprocessing/multibuild stuff and some |
28 |
test phases that need to spawn servers. It ensures that portage does |
29 |
not leave any orphans that would otherwise need to be separately |
30 |
tracked and killed. |
31 |
|
32 |
Control groups are applied to src_* phases only, since we expect that |
33 |
pkg_postinst() may restart external daemons, and those could end up |
34 |
being attached to the cgroup. |
35 |
|
36 |
I doubt this could break something. |
37 |
|
38 |
|
39 |
2. FEATURES=network-sandbox |
40 |
|
41 |
Requires: CONFIG_NAMESPACES, CONFIG_NET_NS |
42 |
|
43 |
Applies to: src_* except for src_unpack |
44 |
|
45 |
This one uses the unshare() syscall to detach the build process from |
46 |
host's network stack. This effectively means that each of the listed |
47 |
phases will be able only to access a detached, 'local' loopback |
48 |
interface and nothing else. |
49 |
|
50 |
This has a few implications. First of all, ebuilds that used to access |
51 |
the Internet won't be able to do that anymore. In the Python world, |
52 |
this would mean that some packages will start to fail properly instead |
53 |
of downloading missing dependencies. It will also break or skip all |
54 |
the tests that rely on the network being available. |
55 |
|
56 |
Secondly, this will prevent any kind of communication between host |
57 |
network and ebuild, including services running on 127.0.0.1. That is, |
58 |
ebuild will no longer be able to access production services running |
59 |
on the host. This affects e.g. old mongodb frontend ebuilds which used |
60 |
to run tests on the live database server (yep, create and delete |
61 |
databases there). |
62 |
|
63 |
Thirdly, this will prevent the daemons spawned within ebuild from being |
64 |
publicly accessible. That is, if test phase spawns some kind of TCP/IP |
65 |
server, even local users won't be able to connect to it (outside of |
66 |
the namespace). This should improve the security. |
67 |
|
68 |
This does not apply to pkg_* phases where networking may be needed for |
69 |
some kind of IPC, and src_unpack where it is used for VCS fetching. If |
70 |
we introduce separate src_fetch in a future EAPI, the exclude will |
71 |
move there. |
72 |
|
73 |
This one's going to trigger a lot of breakage in ebuilds. Therefore, |
74 |
I'd appreciate if developers started using it early and fixing |
75 |
the ebuilds. |
76 |
|
77 |
|
78 |
3. FEATURES=ipc-sandbox |
79 |
|
80 |
Requires: CONFIG_NAMESPACES, CONFIG_IPC_NS |
81 |
|
82 |
Applies to: src_* |
83 |
|
84 |
This one separates the ebuild's *nix IPC stuff from host. This includes |
85 |
semaphores, shared memory etc. Similarly to network-sandbox, this could |
86 |
prevent ebuilds from communicating with some production servers. |
87 |
|
88 |
But honestly, I have no idea if anything really does it or relies on it. |
89 |
I doubt this could break something but it's worth testing. |
90 |
|
91 |
|
92 |
I'd really appreciate some testing and feedback. Thanks. |
93 |
|
94 |
-- |
95 |
Best regards, |
96 |
Michał Górny |