3 ms·
It's worse on several levels. The first thing containers do is take away the tools needed (unshare, seccomp syscalls) for an application to secure itself or its
by the8472 8y ago
It's worse on several levels. The first thing containers do is take away the tools needed (unshare, seccomp syscalls) for an application to secure itself or its children.
The pledge/unveil model is far more elegant.
> What does it do to memory usage, and disk usage?
You'd need a deduplicating filesystem, i.e. btrfs for the storage aspect.
For memory consumption you either have to rely on KSM or hope that they will implement page cache sharing it for btrfs. Overlayfs has it but it's less space-efficient.
But I agree that this shouldn't be needed because containers shouldn't each ship with their own OS disk image. That's not orthogonal to the security aspect.
- beojan 8y ago> You'd need a deduplicating filesystem Until all your packages decide to use different versions of their dependencies.
- muraiki 8y agoI found this thread which has some stats on the memory savings achieved through KSM, but the results weren't very impressive.
- compsciphd 8y agoyou don't need deduplicating file system or ksm. regular file systems and regular shared read only code pages work fine. see the links I posted above, if every package (or a subset of packages based on the underlying source package) in a traditional linux distribution is treated as an independent layer that can be composed together on demand (i.e. what happens when you install a package, except much slower) using a traditional union file system you get deduplication (as every image using that package will be sharing the same exact portion of the file systme) and you get memory sharing for free (for exact same reason, as its fundamentally no different than multiple processes on a single host dynamically linking the same binaries).
- deleted 8y ago[deleted]
- the8472 8y agoIn practice containers are siblings with a lot of redundant data, not a layer cake.