this post was submitted on 28 Sep 2026
12 points (80.0% liked)
Security
2174 readers
54 users here now
A community for discussion about cybersecurity, hacking, cybersecurity news, exploits, bounties etc.
Rules :
- All instance-wide rules apply.
- Keep it totally legal.
- Remember the human, be civil.
- Be helpful, don't be rude.
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You definitely don't need containers to "run something that needs a different dependency", it's a massive waste of time and resources and just not what containers were made for. There are/were a thousand other solutions for this, from Nix to
chrootto building from source toLD_LIBRARY_PATHto AppImage.Containers were initially sold as a "security boundary" of sorts. The ability to run some software with the peace of mind that it won't ruin your OS or leak all your data if it's vulnerable. It's the entire point, but it turns out to be extremely difficult to get right. We managed to make a boundary against accidentally messing something up, not against targeted attacks.
You're talking about sandbox type container-based app packaging, like flatpak, appimage, or snaps I think. Containers in the libcontainer/docker sense were always supposed to be "lightweight self-contained runtime environments." It simplified deployment and operations by decoupling infrastructure from code. If it were made with security applications in mind from the start, rootless would have been supported properly
Yeah, but Nix and every other solution you mentioned has their own tradeoff and ease of use friction between developer and devops. Containers have good ergonomics for both that it reduces friction to achieve ci/cd