11 ms·
My shortcut for answering these questions is just replace 'container' with process and find the answer for that. A running container is just a process that is
by adamgordonbell 4y ago
My shortcut for answering these questions is just replace 'container' with process and find the answer for that.
A running container is just a process that is using certain kernel features: cgroup, namespaces, pivotroot.
LXC has a different DX around containers than OCI containers do, but the same rules apply.
- sgt 4y agoDX?
- adamgordonbell 4y agoDeveloper Experience (Maybe there is a better term, but how you use them) Docker/ OCI containers tend to be a single process and LXC containers have a collection of processes. But in either case they are just processes running on the host in a different namespace. So they feel different to use, but use the same building blocks (to my understanding).
- sgt 4y agoUnrelated, but your name rang a... bell. You're the corecursive guy. Great podcast!
- adamgordonbell 4y agoThanks!
- Karellen 4y agoShouldn't "DX" refer to the experience of people hacking on the Docker (or whatever) code itself? Like... how easy the build system is to work with if you're adding a new source file to the docker codebase? The people working with Docker, even if they are developers doing development work, are still users of Docker, aren't they? I mean, the GUI of an IDE is still part of its UX, right? Even though it's for developers doing development work?
- adamgordonbell 4y agoI was thinking that developer experience is user experience – where the user is a developer. You are suggesting that the user and developer are different roles because even when the user is a developer there is still the developer who builds that tool It's possible you are right but I'm not an expert. I always think of the developer experience is the experience of developers using the tools and APIs you produce.
- dwb 4y ago[flagged]
- commandersaki 4y agoOne exercise on pwn.college in their kernel security module is they have a program that forks, opens the flag file (/flag owned by root), reads the content, and then child process exits. The program continues to run to allow you to load in shell code that'll be run by the kernel. Your task is basically to write some shellcode to scan the memory for the flag. So now I know that at least some Linux-es don't clean up after a process exits, and you can get the contents of memory when you have kernel privileges. This is not so easy if you're scanning memory as root since /dev/mem or whatever won't reveal that process memory.
- zamnos 4y agohere, I made it clickable: http://pwn.college http://pwn.college
- gaudat 4y agoOh it is free too. Gotta try this.
- djbusby 4y agoThe memory wipe is a kernel build-time config option.
- CodesInChaos 4y agoDo you know what the option is called? edit: apparently the runtime option is called `init_on_alloc` and the compile-time option (which determines the default of the runtime option) is called `CONFIG_INIT_ON_FREE_DEFAULT_ON`.
- tomcam 4y agoThank you! Annoyed at myself for not thinking it through that way.