61–70 of 75 posts
Earlier quoted context omitted.
docker has to do with ships and barco means ship.
It's funny that three people feel the urge to reply for the author and all of them are wrong :-) Also I find it interesting that in Portuguese as well as in Spanish the word exists in both genders: el barco, la barca, o barco, a barca.
Earlier quoted context omitted.
It's funny that three people feel the urge to reply for the author and all of them are wrong :-) Also I find it interesting that in Portuguese as well as in Spanish the word exists in both genders: el barco, la barca, o barco, a barca.
At least in Spanish, my rule of thumb is that "barco" is for bigger boats and "barca" is for smaller ones (and then you have Barça which is the football/soccer team).
Earlier quoted context omitted.
> 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…
1. Containers predate Linux, appeared in other UNIXes before GNU/Linux, and Windows also has them. 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
barco 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?
Their explanation:
"While most of the tools used in the Linux containers ecosystem are written in Go, I believe C is a better fit for a lower level tool like a container runtime. runc, the most used implementation of the OCI runtime specs written in Go, re-execs itself and use a module written in C for setting up the environment before the container process starts.
crun aims to be also usable as a library that can be easily included in programs without requiring an external process for managing OCI containers."
barco 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?
Earlier quoted context omitted.
1. Containers predate Linux, appeared in other UNIXes before GNU/Linux, and Windows also has them. 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
It depends what you mean by "container". As far as I know, Windows containers aren't using namespaces, cgroups and seccomp. BSD Jails are definitely a different thing. So if you wanted to know how exactly linux containers worked, it's probably easiest to use what the linux docs provide (which is C).
Just like HP-UX vaults, and Solaris Zones aren't using namespaces, cgroups and seccomp, rather their own UNIX flavours.
Earlier 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…
Wouldn't "runtime.LockOSThead()" help with the single-threaded API?
There is no way to make an entire Go program run as a single threaded program without using CGo the way we do in runc. Even GOMAXPROCS=1 doesn't work. CLONE_NEWUSER will always fail in a multi-threaded program.
Earlier 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…
> 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 we use in runc not work. [...] Neither of these issues exist in C programs. This issue doesn't intrinsically affect Rust as a language (when compared to C), because you can just do exactly the same thing as you'd have done in C: let fd = libc::open(b"/path\0".as_ptr().c…
In general, C programs do not require workarounds for dealing with kernel APIs for the simple reason that the vast majority of kernel APIs are developed with test programs written in C, so kernel developers will usually not design an API that is awful to use in C.
Another thing that surprised me when I first started programming in Rust is that:
let fd = File::open("foo")?.as_raw_fd();
let f = File::open("foo")?;
let fd = f.as_raw_fd();
Earlier quoted context omitted.
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…
Possibly, but I'd say that Google's experience with kCTF was that allowing io_uring on hosts running containers has allowed for multiple breakouts. They paid out over $1m on io_uring related bug bounties https://security.googleblog.com/2023/06/learnings-from-kctf-... Also while user namespaces help in theory, in practice expanding the attack surface of the kernel exposed to unprivileged users has consequences in allo…
> Also while user namespaces help in theory
You should use user namespaces to contain untrusted code, you absolutely should not enable CLONE_NEWUSER inside a container. I was referring to the former, you're talking about the latter.