Richard Guy Briggs <rgb@xxxxxxxxxx> writes: > The trigger is a pseudo filesystem (proc, since PID tree already exists) > write of a u64 representing the container ID to a file representing a > process that will become the first process in a new container. > This might place restrictions on mount namespaces required to define a > container, or at least careful checking of namespaces in the kernel to > verify permissions of the orchestrator so it can't change its own > container ID. Why a u64? Why a proc filesystem write and not a magic audit message? I don't like the fact that the proc filesystem entry is likely going to be readable and abusable by non-audit contexts? Why the ability to change the containerid? What is the use case you are thinking of there? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
