1 |
On Fri, Sep 22, 2017 at 7:26 PM, Rich Freeman <rich0@g.o> wrote: |
2 |
>On Fri, Sep 22, 2017 at 6:29 PM, James McMechan <james_mcmechan@×××××××.com> wrote: |
3 |
>> On Fri, Sep 22, 2017 at 5:18 PM, Rich Freeman <rich0@g.o> wrote: |
4 |
>>>On Fri, Sep 22, 2017 at 4:43 PM, James McMechan |
5 |
>>><james_mcmechan@×××××××.com> wrote: |
6 |
>>>> |
7 |
>>>> # now create a separate mount namespace non-persistent |
8 |
>>>> unshare -m bash |
9 |
>>>> |
10 |
>>> |
11 |
>>>If you're going to go to the trouble to set up a container, you might |
12 |
>>>as well add some more isolation: |
13 |
>>> |
14 |
>>>unshare --mount --net --pid --uts --cgroup --fork --ipc --mount-proc bash |
15 |
>>> |
16 |
>> |
17 |
>> I would not want to change the networking, it should already be working |
18 |
>> and I would be better served by not messing with it. |
19 |
>> |
20 |
> |
21 |
>Well, that's the point. You don't want networking to work during the |
22 |
>build phases. Maybe you'd want it for the test phase. In any case, |
23 |
>you would definitely want control over that in the ebuild. Random |
24 |
>build systems shouldn't be talking to the internet, if for no other |
25 |
>reason than to avoid it fetching stuff to install that bypasses the |
26 |
>integrity checks. |
27 |
> |
28 |
>If you create a new net namespace by default it won't have any |
29 |
>interfaces other than lo. |
30 |
|
31 |
Err, perhaps I was thinking of doing the switch too early, I had been thinking |
32 |
of making sure networking works for the fetch phase... |
33 |
|
34 |
>> The --mount-proc is not really helpful as I immediately remount the entire |
35 |
>> "/" filesystem at /mnt/gentoo and chroot into it after custom setup of proc sys and dev |
36 |
>> |
37 |
> |
38 |
>As long as it doesn't see the host /proc then you're fine. You just |
39 |
>wouldn't want to have it mounted into the container. |
40 |
|
41 |
I am pretty sure a /proc needs to be mounted inside of any container if you want builds |
42 |
to work. mount, ps, and a lot of other stuff does not work without it. |
43 |
|
44 |
I think you mean that only the container /proc is mounted. |
45 |
|
46 |
>> Now I could see a use for --map-root-user --user, then portage could run as |
47 |
>> root in the container with the least danger by being user portage:portage outside. |
48 |
>> |
49 |
> |
50 |
>Certainly, but that takes a bit more work, and to be honest I've never |
51 |
>actually bothered to get it working using unshare. It probably isn't |
52 |
>too difficult. |
53 |
|
54 |
You were right, I just tried it and it seemed easy enough. |
55 |
|
56 |
>The options I listed basically "just work" without any real additional effort. |
57 |
|
58 |
I like the lack of effort part ;) I want the computer doing the work not me. |
59 |
|
60 |
>So, we're drifting in topic, but as long as we're coming up with |
61 |
>nice-to-have utilities it would be lovely if our install CDs had |
62 |
>something similar to systemd-nspawn to set up a container instead of a |
63 |
>chroot for performing the install. If nothing else it would make |
64 |
>mount cleanup easier when you're done. I imagine it would just be a |
65 |
>bit of shell scripting with util-linux on the CD - while nspawn is |
66 |
>bundled with systemd you don't need any of its fancier features for |
67 |
>doing an install. |
68 |
|
69 |
Ok, but what is the advantage? the mounts disappearing when you exit |
70 |
the container, and anything else? |
71 |
|
72 |
>Back on topic - none of this stuff will work on FreeBSD, which might |
73 |
>be an issue for those running Gentoo on that kernel. Ditto for Prefix |
74 |
>I suppose. I suspect that jails/etc would also do the job but you'd |
75 |
>need some arch-dependent code to set up the container. Just about all |
76 |
>of these tricks are involving non-POSIX functionality. Actually, I'm |
77 |
>not sure if even the current LD_PRELOAD approach is completely |
78 |
>portable, though it has the advantage of being entirely in userspace. |
79 |
|
80 |
I don't see any BSD stuff on the download page, so it slips my mind. |
81 |
|
82 |
I have not used any of the BSD derived systems in quite a few years. |
83 |
A quick glance shows they are running things like docker so container |
84 |
like functionality exists, and I seem to remember that Linux was late to |
85 |
the overlay stuff, the freeBSD mount_unionfs says it went in as |
86 |
mount_null in 4.4BSD according to the man page so that is present also. |
87 |
|
88 |
Regarding prefix, or maybe RAP does sandbox even work there? |
89 |
|
90 |
It looks like prefix uses the host system's library... would either method |
91 |
sandbox currently uses work? |
92 |
|
93 |
RAP appeared to have it's own C library so it should be possible there |
94 |
I do not remember if sandbox worked under RAP it the whole project felt |
95 |
very experimental when I tried it. |
96 |
|
97 |
I think non-linux systems did adopt LD_PRELOAD and ptrace some, |
98 |
I do not think either was in any of the POSIX versions though I did not |
99 |
look much at the last version, it seemed mostly irrelevant by then. |
100 |
|
101 |
Enjoy, |
102 |
|
103 |
Jim McMechan |