Richard Guy Briggs <rgb(a)redhat.com> 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