Reusing cgroup instances

[AlphaNecron]

Is it a bad practice to reuse cgroup instances? For example, if I have 10 test cases, by using shared cgroup instance, will memory.max_usage be the maximum value of 10 runs or each run?

[criyle]

The memory.max_usage can be cleared but the memory cgroup will keep the cached file into its calculation from previous executions. That makes memory.max_usage unreliable.

[criyle]

During my research, this sandbox implementation uses cgroup pool and calculating memory usage by memory.max_usage - cache from the memory.stat. However, the result wasn't reliable since cache may be changed after execution and parsing memory.stat is a relatively expensive operation. At the sometime, I think creating cgroup is not an expensive operation (2ms) from benchmark so it is not worthing to make a pool for cgroups.

[AlphaNecron]

Thanks. I'm creating a cgroup instance for each process.

[AlphaNecron]

Anyways, is seccomp needed inside container? Are there risks without seccomp added? Tried seccomp filter but the program does not exit immediately after several syscalls.

[criyle]

Personally, no and seccomp is disabled by default during compile time. The user program is running without any privilege and controlled by no new privilege flag In restricted readonly file system, so it cannot gain privilege or escape from the container. Without seccomp added, if there's any CVE in kernel that provides container escape mechanism using a rare used syscall, the system could be hacked. However, the risk is very low since I only heard only one bug in kernel during early development of container.

If you are using executor_server to test seccomp, you need to build with -tag seccomp to enable it.

[AlphaNecron]

Using go-sandbox directly anyways. Thanks for replying.