Hi Serge,
> Ah, no, mountall just gets upset about some forced readonly
> mounts. lxc.mount.auto = proc always worked for me. If I do
>
> - r = mount("sysfs", path, "sysfs", MS_RDONLY, NULL);
> + r = mount("sysfs", path, "sysfs", 0, NULL);
> - mount(NULL, path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
> + //mount(NULL, path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
> then sys and cgroup auto-mount also work. The problem with both is that
> mountall has entries in /lib/init/fstab saying they should be mounted
> readwrite, so it hangs trying to force that to happen.
Ah, ok... :/
> How would you feel about adding a flag to specify whether they should be
> readonly? How would we specify the flag? (Note it's ok for sys to be
> read-write in ubuntu since apparmor confines it. cgroups by default are
> too, but we don't have a good way yet to generate policy which will allow
> /sys/fs/cgroup/$controller/$container-cgroup-path/ to be written to but the
> /sys/fs/cgroup/$controller not)
I could get behind the following:
proc - always read-write (no harm AFAICT)
sys - default: read-only
sys:rw - read-write
sys:ro - explicit read-only
cgroup:ro - completely ro (including paths)
cgroup:rw - completely rw (including paths)
cgroup:mixed - paths ro, other rw
cgroup - defaults to cgroup:mixed
Also, I could imagine adding
cgroup-full:ro - mount complete tree read-only (not just partial)
cgroup-full:rw - mount complete tree read-write (not just partial)
cgroup-full:mixed - mount complete tree read-only but bind-mount
partial tree read-write
cgroup-full - defaults to cgroup-full: mixed
Thoughts?
-- Christian
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Lxc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxc-devel
