Linux containers in 500 lines of code (2016)
blog.lizzie.io
blog.lizzie.io
I like to think that there are sufficient code comments and docstrings to help demystify what is going on under the hood with containers.
(eqv? #\1 (call-with-input-file userns-file read-char))
specifically the #\1?This would seem to better guard against accidentally missing existing capabilities, and also protect against newer capabilities that might be added in a future kernel.
But on the top of the article, the author explicitly recognzied this and explained why they went down that route:
> I wanted specifically to find a minimal set of restrictions to run untrusted code. This isn't how you should approach containers on anything with any exposure: you should restrict everything you can. But I think it's important to know which permissions are categorically unsafe!
I agree, you should iterate over all your existing capabilities and drop those that are not in the white-list. (I have implemented this functionality in one of my projects this way.)
BUT:
Maybe the reason some people do it otherwise, is that capabilities API have only a drop function for the bounding set, and people just don't think they should use it in reverse mode - Sapir-Whorf Hypothesis in operation! ;)
edit: seems like the author have a different reason though
This is a very good piece of writing with extensive references and I'll definitely find this useful to share in the future. She documents a ton of tradeoffs she made and resources she chose not to constrain (including the aforementioned syscalls and capabilities), which is important in this type of design and something that I wish I saw more of.
[1]: https://github.com/jessfraz/contained.af/blob/master/seccomp...
I've just printed it out, and it literally contains 100 page of explanation and context for that 500 lines of code. Great work!
somewhat unrelated, I don't use emacs but is there a way to break lines such as
#+caption: [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....]
in the org mode source? https://blog.lizzie.io/linux-containers-in-500-loc.org
They're easier on my eyes. They're easy to bookmark forever. You can sort your books in a way that the physical placement of your book itself (the thickness, the colors, whatever) helps you organize or remember important details instead of just getting lost in a pile of ebooks in folders. And the backlights are bad for trying to fall asleep while reading which may sound odd, but I have the _least_ ADD when I'm about to fall asleep and everything calms down so I learn the best.
I use ebooks, but I absolutely prefer the real thing whenever possible.
And I say all of this as someone who has given away all of his DVDs and won't buy BluRays for his movie collection. I'd rather just rip something and dump it to my hard drive. Those little DVD boxes were filling many shelves and I was like "Why? All I do is watch them. And the bloody intro ads treat me like I'm a pirate for buying them."
So my point there is, I'm not just some sentimental person who clings to physical things. I like my physical books because they're better for me.
But, I'm not some zealot who thinks, "Anyone who uses ebooks is wrong/worse/whatever."
Have you ever dropped a book and lost your page? What a tragedy :)
I get the other parts, but this is the one thing where having it in a computer format would be _more_ practical. :-) I would rather go the opposite way, i.e. scan physical book for the purpose of keeping a backup.
So much more information is retained I find doing it this way over using Visio or Sublime.
This is one thing I hate about Apple these days. They once had pdf versions of all the developer documents but now they only have web pages and Xcode. For a company so concerned about users, they sure don’t seem to care about developer’s eye strain.
The Apple HIG (Human Interface Guidelines) used to be a great document to have printed out and left lying around for reference, and as a starting point for discussion.
Also, there's no Amazon take backs.
Anyways, I find reading on paper so much better than reading E-Ink as well, got a Kindle paperwhite, and it's out of battery somewhere because highlighting and note-taking (I do it a lot while studying) feels so much better with physical copies. Only reason for me to take the Kindle for a walk is when I'm traveling and weight is a concern.
Writing this kind of stuff from scratch is good fun, and really helps understand the underlying kernel features.
[1] https://github.com/moby/moby/blob/a27b4b8cb8e838d03a99b6d2b3...
Really nice example of the power of literate programming in general and of org-mode's support for it in particular.