<div dir="ltr"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 1, 2018 at 2:16 PM, kemi <span dir="ltr"><<a href="mailto:kemi.wang@intel.com" target="_blank">kemi.wang@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
On 2018/11/1 下午2:53, Fajar A. Nugraha wrote:<br>
> On Thu, Nov 1, 2018 at 1:38 PM, kemi <<a href="mailto:kemi.wang@intel.com">kemi.wang@intel.com</a>> wrote:<br>
> <br>
>>>> g) and h) read files from /proc, not cgroup. You need lxcfs. You should<br>
>>>> already have that on ubuntu though.<br>
>>>><br>
>>>><br>
>><br>
>> /proc/cpuinfo also matches the expected result.<br>
>> However, it seems that sysfs in container still shares with host /sys<br>
>> file system.<br>
>> Right?<br>
>><br>
>><br>
>><br>
> Correct. See <a href="https://linuxcontainers.org/lxcfs/introduction/" rel="noreferrer" target="_blank">https://linuxcontainers.org/<wbr>lxcfs/introduction/</a><br>
> <br>
<br>
</span>OK, then I have a question on scalability and security issues on running multiple containers.<br>
<br>
Background: Our customers hope to run hundreds or even thousands of containers in their production environment. <br>
<br>
Sharing sysfs of containers with host sysfs in lxc/lxd may have:<br>
a) security issue.<br>
If a malicious program in a container changes a sensitive file in /sys,<br>
e.g. reduce CPU frequency, does it really works? Does it affect other running containers?<br>
<br></blockquote><div><br></div><div><br></div><div>Why don't you try it and see :)</div><div><br></div><div>Even privileged container should get something like this</div><div><br></div><div><div># echo 1000000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq</div><div>-su: /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq: Read-only file system</div></div><div> </div><div><br></div><div>There were some known security issues with /sys in the past (not cpufreq though), but even back then it should be non issue for the default lxd containers, which are unprivileged.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
b) Scalability issue.<br>
E.g. During launching a ubuntu OS(not kernel) or Android OS in a container,it usually use udev/ueventd<br>
to manage their device. This device manager daemon will read or write uevent file in /sys, the kernel<br>
then broadcast a uevent to all the listeners(udev daemon) via netlink, if there are already hundreds<br>
of containers in the system, all of udev daemons need to deal with it, it would lead to a long boot<br>
latency which we have observed in docker.<br>
<br></blockquote><div><br></div><div>LXD containers don't use udev.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyway to fix that?<br>
</blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Try it, and if you find anything wrong, ask.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- </div><div class="gmail_extra">Fajar</div></div></div>