On 2018/11/1 下午3:30, Fajar A. Nugraha wrote: > On Thu, Nov 1, 2018 at 2:16 PM, kemi <[email protected]> wrote: > >> >> >> On 2018/11/1 下午2:53, Fajar A. Nugraha wrote: >>> On Thu, Nov 1, 2018 at 1:38 PM, kemi <[email protected]> wrote: >>> >>>>>> g) and h) read files from /proc, not cgroup. You need lxcfs. You >> should >>>>>> already have that on ubuntu though. >>>>>> >>>>>> >>>> >>>> /proc/cpuinfo also matches the expected result. >>>> However, it seems that sysfs in container still shares with host /sys >>>> file system. >>>> Right? >>>> >>>> >>>> >>> Correct. See https://linuxcontainers.org/lxcfs/introduction/ >>> >> >> OK, then I have a question on scalability and security issues on running >> multiple containers. >> >> Background: Our customers hope to run hundreds or even thousands of >> containers in their production environment. >> >> Sharing sysfs of containers with host sysfs in lxc/lxd may have: >> a) security issue. >> If a malicious program in a container changes a sensitive file in /sys, >> e.g. reduce CPU frequency, does it really works? Does it affect other >> running containers? >> >> > > Why don't you try it and see :) >
this is just an example I used to help describe my question clearly. I believe there are some other security issues in lxc/ldx due to shared sysfs. > Even privileged container should get something like this > > # echo 1000000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq > -su: /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq: Read-only > file system > > > 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. > > Yes. Using unprivileged container is a workaround, not very good though. > > b) Scalability issue. >> E.g. During launching a ubuntu OS(not kernel) or Android OS in a >> container,it usually use udev/ueventd >> to manage their device. This device manager daemon will read or write >> uevent file in /sys, the kernel >> then broadcast a uevent to all the listeners(udev daemon) via netlink, if >> there are already hundreds >> of containers in the system, all of udev daemons need to deal with it, it >> would lead to a long boot >> latency which we have observed in docker. >> >> > LXD containers don't use udev. > I have no idea on how LXD container works now. Maybe udev is disabled or some other mechanism may be used to manage device. > > >> Anyway to fix that? >> > > > Try it, and if you find anything wrong, ask. > The reason why I have not tried it is there is no available android image provided on existed images server for LXD container. Do you know something about that? So, I have to make a Android image first. Anyway I will try it next. Thx for your answers again. _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
