Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev-announce@l.g.o
Cc: gentoo-dev@l.g.o
Subject: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
Date: Tue, 20 Aug 2013 10:33:11
Message-Id: 20130820122603.54496cf1@gentoo.org
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies