[flagged]
Why would there be any conflict? They're in completely different domains so there is no potential for confusion. Why would copyright be relevant in any way? Do you even know what copyright is?
Barco: Linux Containers from Scratch in C
41–50 of 75 posts
Re: Barco: Linux Containers from Scratch in C
#42Earlier quoted context omitted.
Looks like a good project to learn container from scratch. Just wondering the main reason you're C since most of the container project now seems to be using Go or Rust?
As the maintainer of a Go container runtime (runc), and having worked with Rust in various other projects, while they can be better languages for building large projects, they make it harder to understand what exactly your program is doing when writing software like this. One example that immediately comes to mind from Rust is a bug with O_PATH file descriptors I found a while ago[1], which would've made certain code…
Re: Barco: Linux Containers from Scratch in C
#43Earlier quoted context omitted.
>Aren't containers never suitable for running untrusted code? They are suitable provided the kernel is secure.
This is tautologically true -- "Is X secure? Yes, assuming the technology X uses is secure." The more nuanced answer is that containers have several layers of protections (seccomp, LSMs, user namespaces, namespaces, cgroups, capabilities, and standard process permissions by running as an unprivileged user) which all act together to help protect against container attacks. It's not perfect, but most container breakout…
Also while user namespaces help in theory, in practice expanding the attack surface of the kernel exposed to unprivileged users has consequences in allowing container breakout (e.g. CVE-2022-0185) also more recently CVE-2023-3390
Re: Barco: Linux Containers from Scratch in C
#44Earlier quoted context omitted.
Looks like a good project to learn container from scratch. Just wondering the main reason you're C since most of the container project now seems to be using Go or Rust?
As the maintainer of a Go container runtime (runc), and having worked with Rust in various other projects, while they can be better languages for building large projects, they make it harder to understand what exactly your program is doing when writing software like this. One example that immediately comes to mind from Rust is a bug with O_PATH file descriptors I found a while ago[1], which would've made certain code…
Re: Barco: Linux Containers from Scratch in C
#45Earlier quoted context omitted.
As the maintainer of a Go container runtime (runc), and having worked with Rust in various other projects, while they can be better languages for building large projects, they make it harder to understand what exactly your program is doing when writing software like this. One example that immediately comes to mind from Rust is a bug with O_PATH file descriptors I found a while ago[1], which would've made certain code…
Those Rust and Go bugs aren't much different from C gotchas when writing portable UNIX code.
Maybe, but:
1. It's irrelevant to this product (no one is writing portable UNIX code when they are writing some Linux-specific software, like container implementations).
and
2. It's irrelevant to the author's goals (learning Linux kernel stuff using the language that the interface to the kernel uses is a better idea than using a different language and hacking shims for all the stuff you want to do).
and
3. The cost to switch to a new language is substantial, and only makes sense if you're either joining a team and project that uses that new language, or if the goal is to learn that new language.
Re: Barco: Linux Containers from Scratch in C
#46Earlier quoted context omitted.
Those Rust and Go bugs aren't much different from C gotchas when writing portable UNIX code.
> Those Rust and Go bugs aren't much different from C gotchas when writing portable UNIX code. Maybe, but: 1. It's irrelevant to this product (no one is writing portable UNIX code when they are writing some Linux-specific software, like container implementations). and 2. It's irrelevant to the author's goals (learning Linux kernel stuff using the language that the interface to the kernel uses is a better idea than us…
2. Any languge able to call into Linux API surface is usable. And if we go down the UNIX native languages route born at Bell Labs, C++ also counts.
3. That depends on how much someone knows C (properly), versus other alternatives
Re: Barco: Linux Containers from Scratch in C
#47Very cool, I was thinking of doing something similar in windows
What is the underlying isolation technology that would be used in windows?
Re: Barco: Linux Containers from Scratch in C
#48Re: Barco: Linux Containers from Scratch in C
#49Could this also be implemented as a bashscript?
Re: Barco: Linux Containers from Scratch in C
#50barco is a project I worked on to learn more about Linux containers and the Linux kernel, based on other guides on the internet.
Looks like a good project to learn container from scratch. Just wondering the main reason you're C since most of the container project now seems to be using Go or Rust?