News for hackers. Stuff that matters.

A comment on Containers as Kernel Objects – Again. Parent comment

Re:Containers as Kernel Objects – Again by dastx on Sunday February 24, 2019 @08:51AM (#19238547)
How so?
[ Parent | on HN ]
Re:Containers as Kernel Objects – Again by k__ on Sunday February 24, 2019 @09:01AM (#19238573)
On trusting trust
[ Parent | on HN ]
Re:Containers as Kernel Objects – Again by gigatexal on Sunday February 24, 2019 @10:18AM (#19238849)
How would you be able to root out these containers doing seemingly anything sitting in kernelspace?
[ Parent | on HN ]
Re:Containers as Kernel Objects – Again by cpuguy83 on Sunday February 24, 2019 @10:28AM (#19238889)
The code wouldn't be running in kernel space, just the setup/configuration of the environment, which really isn't any different than it is today, tbh. This seems to be more about attaching a kernel auditable id to a container.
[ Parent | on HN ]
Re:Containers as Kernel Objects – Again by metabagel on Sunday February 24, 2019 @12:42PM (#19239564)
It sounds like what you are talking about is already existing functionality, not the proposed design.
[ Parent | on HN ]
Re:Containers as Kernel Objects – Again by simcop2387 on Sunday February 24, 2019 @02:13PM (#19240055)
The proposed design uses all the existing functionality and gives it a single object in the kernel to control it rather than a dozen different ones. It's not a fundamental change in design to how the containers themselves work.
[ Parent | on HN ]
Re:Containers as Kernel Objects – Again by gigatexal on Sunday February 24, 2019 @05:29PM (#19241042)
Ahh, well I stand corrected.
[ Parent | on HN ]