Comment on Alpine Linux intro

oshu@lemmy.world ⁨2⁩ ⁨months⁩ ago

• ntn888@lemmy.ml ⁨2⁩ ⁨months⁩ ago

  yeah, but any update failure of a container is less fatal. and only affects the isolated service… it’s way easy to manage this situation than an unbootable server.

  source

  • oshu@lemmy.world ⁨2⁩ ⁨months⁩ ago

    How so? if I compromise a containerized app I get all the data that app has access to.

    From a security standpoint, each and every container running actually increases the potential attack surface.

    source

    • lambalicious@lemmy.sdf.org ⁨2⁩ ⁨months⁩ ago

      The attack surface yes, but not the attack volume. No matter if the app is containerized or native, it has access to the data that it has to operate to. That’s literally part of computer nature.

      But a containerized app, assuming the container service itself is kept up to date, has less hooks to break into other stuff than a native app does. For starters, a native app can read everything that’s world-readable, which in a shared system might be lots of stuff but in a containerized app might be quite minimal.

      source
  • hendrik@palaver.p3x.de ⁨2⁩ ⁨months⁩ ago

    But that's very hypothetical. I've been running servers for more than a decade now and never ever had an unbootable server. Because that's super unlikely. The services are contained in to several user accounts and they launch on top of the operating system. If they fail, that's not really any issue for the server booting. It'll just give you a red line in systemctl and not start the service.

    source

    • ntn888@lemmy.ml ⁨2⁩ ⁨months⁩ ago

      I guess you can take more risks if you know what you’re doing :P

      source

      • hendrik@palaver.p3x.de ⁨2⁩ ⁨months⁩ ago

        I don't think so. I've also started small. There are entire operating systems like YunoHost who forgo containers. All the packages in Debian are laid out to work like that. It's really not an issue by any means.

        And I'd say it's questionable whether the benefits if containers apply to your situation. If you for example have a reverse proxy and do authentication there, all people need to do is break that single container and they'll be granted access to all other containers behind that as well... If you mess up your database connection, it doesn't really matter if it runs in a container or a user account / namespace. The "hacker" will gain access to all the data stored there in both cases. I really think a lot of the complexity and places to mess up are a level higher, and not something you'd tackle with your container approach. You still need the background knowledge.

        I don't want to talk you out of using containers. They do isolate stuff. And they're easy to use. There isn't really a downside. I just think your claim doesn't hold up, because it's too general, you just can't say it that way.

        source

        • -> View More Comments