5 ms·

Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux. Edit: Are snaps images? ...like containers? Edit 2: an

by ncr100 6y ago

Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux. Edit: Are snaps images? ...like containers? Edit 2: answer: > mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application

solarkraft 6y ago
The main (and better supported) competitor is Flatpak, which at least doesn't have the terrible marketing.
- ncr100 6y ago
  Thank you - :) Reading about the cons of Snap now - "auto-updates cannot be turned off" - https://en.wikipedia.org/wiki/Snap_(package_manager) https://en.wikipedia.org/wiki/Snap_(package_manager)
  - nawgszy 6y ago
    Just what we all want on our production hosts.
    - entropicdrifter 6y ago
      Especially when they're being installed covertly through APT
  - _jal 6y ago
    Yep. One of many reasons they're banned in our shop. Even for client software it is bad - an app quitting out from under me because it wants to update is functionally equivalent to a crashing bug - but they're offering daemons this way, which is just insane. Who doesn't want all their containers randomly restarting because someone up the distro chain decided when your machine needed to upgrade? https://snapcraft.io/lxd https://snapcraft.io/lxd
    - tomponline 6y ago
      The containers do not restart when the snap package is updated.
    - tssva 6y ago
      If snap decides to update lxd on the nodes of your lxd cluster at the same time that a node has failed it is a CF. The cluster will not come up because your down node is now not the same version as the other cluster nodes.
    - Lorkki 6y ago
      > an app quitting out from under me because it wants to update This doesn't happen, at least on account of Snap. It's copy-on-write when it comes to updates, and whatever version you have running at the time of update will happily keep on running. I've been mildly confused by this a couple times, when I would end up with two different versions of VS Code running side by side, but the bright side was that my work wasn't interrupted. It incidentally also sidesteps all the problems that stem from libraries or configuration being updated under a running application, which can happen with Apt.
  - xet7 6y ago
    Auto-updates of all Snap packages can be turned off at /etc/hosts by adding a line: 127.0.0.1 api.snapcraft.io
    - bscphil 6y ago
      This is sort of like saying you can turn off auto-updates by leaving your Internet connection disabled - true, but missing the point that what people are primarily complaining about is having to adopt an adversarial relationship to the software they use.
- superkuh 6y ago
  All containerization is just the fever to the sickness that is the futureshock from extremely fast rate of development of major libs like c++$year, glibc (no matter what they say about having stable endpoints), and the like. You can't run a program written today on the system repo libraries from 5 years ago. Containers try to mitigate this problem but like a fever they often end up making things worse.
  - zentiggr 6y ago
    I don't run any APT based distribution right now but I understand the issues... I think the biggest problem I see is Canonical developing what looks like a very useful tool but holding it proprietary. If Canonical provided the snap creation and hosting tools to the community I imagine it would be judged on its technical merits. As it is, I see more and more reports that Canonical is trying to gain more and more control and that's exactly what I don't like to see. Would have tried Ubuntu but they've poisoned that well. I'll have to recalculate.
    - xav0989 6y ago
      As far as I can tell, snapcraft[0], the tool that allows the creation of snaps is open-source and on github. However the hosting server-side code is closed source. [0]: https://github.com/snapcore/snapcraft https://github.com/snapcore/snapcraft
  - drewg123 6y ago
    Wouldn't it just be simpler to statically link apps then?
    - enriquto 6y ago
      Indeed! All this "packaging abstraction" stuff is ridiculously silly when you can simply distribute a static binary.
  - solarkraft 6y ago
    Do you see the fast development itself as a problem? I tend to see as the real issue that most package managers only allow one version of a package to be installed, leading to conflicts very quickly. The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?
- AnIdiotOnTheNet 6y ago
  Depending on the qualities your after, AppImage is also really great. Advantages over Flatpak are that they are completely portable (you can store them anywhere and run them from anywhere), and they don't require a special runtime or package management infrastructure of any kind.
  - solarkraft 6y ago
    AppImages are basically (kind of) statically linked binaries. Not my favorite to install software since they're usually huge (500mb is not far out of the norm), but great for things that are hard to install, as they're pretty much guaranteed to work. I just wish there was a command line switch to stop it from wanting to install itself on my system (move the AppImage to /opt).
    - AnIdiotOnTheNet 6y ago
      I have never seen that behavior from an AppImage. I just mark them executable and run them and they do their thing. If there is a specific AppImage behaving this way then it is probably the fault of the author, and if all of them are doing it then I wonder if it is the behavior of something like appimaged?
entropicdrifter 6y ago
If you need this kind of packaging but want to retain freedom, just use an alternative solution like flatpak, which sandboxes from the get-go and lets you control what parts of your system the application can access
- ncr100 6y ago
  Neat - "permissions that are defined by the maintainer of the Flatpak and can be controlled (added or removed) by users on their system" - https://en.wikipedia.org/wiki/Flatpak https://en.wikipedia.org/wiki/Flatpak I'm wondering now if Wikipedia would be appropriate to host a linux sandboxed app packaging comparison chart in the form of https://linuxhint.com/snap_vs_flatpak_vs_appimage/ https://linuxhint.com/snap_vs_flatpak_vs_appimage/ - and it would be extensible ...since Wikipedia.
- DoofusOfDeath 6y ago
  > just use an alternative solution like flatpak Saying "just use an alternative" seems overly dismissive of the complications that entails. IIUC, the only options for that are (a) abandon Ubuntu, or (b) actively circumvent Ubuntu's software distribution infrastructure, reminiscent of dealing with Windows 10 forced updates. IMHO this somewhat erodes Ubuntu's value proposition.
  - zentiggr 6y ago
    I have a laptop that I'm planning on rebuilding from a failed NTFS/Win10 system to Linux something. Now I know it's not going to be Ubuntu or anything else derived from Canonical.
    - Endeavourist 6y ago
      Why not EndeavourOS? It's based on Arch Linux, with minimal numbers of external packages; quite unlike Manjaro actually. You can just treat it as a standard Arch install, and even use the ISO to boot with wi-fi drivers and all and install Arch plainly, without the non-wifi and other regrets. EndeavourOS is pretty great; I personally use it as a live-ISO (XFCE environment) and just install Arch from within the live EndeavourOS booted iso. Just throwing it out there.
michaelmrose 6y ago
Sandboxing addresses AN issue but does not address any of the issues discussed in this article. Also sandboxing and running apps under reduced permissions makes a lot of sense but should be seen as a tool to increase security not an answer outright as poorly used any tool can be less effective or even harmful. Historically locking down increasingly effectively often leads to impeding things the user actually wants to do which leads to apps asking for and granting permissions with the net effect of training users click yes to enable whatever the app wants to do. It ends up being not just a technical challenge but a psychological one as well and its less easily resolved once you start having to deal with real users.
blablabla123 6y ago
It seems to incorporate some novel ideas despite its obvious shortcomings. I also think that so far Linux distributions have done very poorly when it came to cross-distribution/forward/backward compatibility of packages. This is a non-issue for popular Opensource packages since they can be easily packaged by the distributors. But not so popular packages sometimes need to be installed in a hacky way when they are not available for the target distribution. Even worse when dealing with commercial software, it can happen that it degrades with each distribution update. Also I think that probably the package format will improve over time and add additional features, that would allow auditing for instance. Also with proper de-duplication (perhaps even on filesystem level) it should be possible to also deal with waste of space.
ex_amazon_sde 6y ago
You can easily create very strong sandboxes for daemons using unit files and packaging them as native OS packages.

by ncr100 6y ago

solarkraft 6y ago

The main (and better supported) competitor is Flatpak, which at least doesn't have the terrible marketing.

ncr100 6y ago
Thank you - :) Reading about the cons of Snap now - "auto-updates cannot be turned off" - https://en.wikipedia.org/wiki/Snap_(package_manager) https://en.wikipedia.org/wiki/Snap_(package_manager)
- nawgszy 6y ago
  Just what we all want on our production hosts.
  - entropicdrifter 6y ago
    Especially when they're being installed covertly through APT
- _jal 6y ago
  Yep. One of many reasons they're banned in our shop. Even for client software it is bad - an app quitting out from under me because it wants to update is functionally equivalent to a crashing bug - but they're offering daemons this way, which is just insane. Who doesn't want all their containers randomly restarting because someone up the distro chain decided when your machine needed to upgrade? https://snapcraft.io/lxd https://snapcraft.io/lxd
  - tomponline 6y ago
    The containers do not restart when the snap package is updated.
  - tssva 6y ago
    If snap decides to update lxd on the nodes of your lxd cluster at the same time that a node has failed it is a CF. The cluster will not come up because your down node is now not the same version as the other cluster nodes.
  - Lorkki 6y ago
    > an app quitting out from under me because it wants to update This doesn't happen, at least on account of Snap. It's copy-on-write when it comes to updates, and whatever version you have running at the time of update will happily keep on running. I've been mildly confused by this a couple times, when I would end up with two different versions of VS Code running side by side, but the bright side was that my work wasn't interrupted. It incidentally also sidesteps all the problems that stem from libraries or configuration being updated under a running application, which can happen with Apt.
- xet7 6y ago
  Auto-updates of all Snap packages can be turned off at /etc/hosts by adding a line: 127.0.0.1 api.snapcraft.io
  - bscphil 6y ago
    This is sort of like saying you can turn off auto-updates by leaving your Internet connection disabled - true, but missing the point that what people are primarily complaining about is having to adopt an adversarial relationship to the software they use.
superkuh 6y ago
All containerization is just the fever to the sickness that is the futureshock from extremely fast rate of development of major libs like c++$year, glibc (no matter what they say about having stable endpoints), and the like. You can't run a program written today on the system repo libraries from 5 years ago. Containers try to mitigate this problem but like a fever they often end up making things worse.
- zentiggr 6y ago
  I don't run any APT based distribution right now but I understand the issues... I think the biggest problem I see is Canonical developing what looks like a very useful tool but holding it proprietary. If Canonical provided the snap creation and hosting tools to the community I imagine it would be judged on its technical merits. As it is, I see more and more reports that Canonical is trying to gain more and more control and that's exactly what I don't like to see. Would have tried Ubuntu but they've poisoned that well. I'll have to recalculate.
  - xav0989 6y ago
    As far as I can tell, snapcraft[0], the tool that allows the creation of snaps is open-source and on github. However the hosting server-side code is closed source. [0]: https://github.com/snapcore/snapcraft https://github.com/snapcore/snapcraft
- drewg123 6y ago
  Wouldn't it just be simpler to statically link apps then?
  - enriquto 6y ago
    Indeed! All this "packaging abstraction" stuff is ridiculously silly when you can simply distribute a static binary.
- solarkraft 6y ago
  Do you see the fast development itself as a problem? I tend to see as the real issue that most package managers only allow one version of a package to be installed, leading to conflicts very quickly. The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?
AnIdiotOnTheNet 6y ago
Depending on the qualities your after, AppImage is also really great. Advantages over Flatpak are that they are completely portable (you can store them anywhere and run them from anywhere), and they don't require a special runtime or package management infrastructure of any kind.
- solarkraft 6y ago
  AppImages are basically (kind of) statically linked binaries. Not my favorite to install software since they're usually huge (500mb is not far out of the norm), but great for things that are hard to install, as they're pretty much guaranteed to work. I just wish there was a command line switch to stop it from wanting to install itself on my system (move the AppImage to /opt).
  - AnIdiotOnTheNet 6y ago
    I have never seen that behavior from an AppImage. I just mark them executable and run them and they do their thing. If there is a specific AppImage behaving this way then it is probably the fault of the author, and if all of them are doing it then I wonder if it is the behavior of something like appimaged?

entropicdrifter 6y ago

If you need this kind of packaging but want to retain freedom, just use an alternative solution like flatpak, which sandboxes from the get-go and lets you control what parts of your system the application can access

ncr100 6y ago
Neat - "permissions that are defined by the maintainer of the Flatpak and can be controlled (added or removed) by users on their system" - https://en.wikipedia.org/wiki/Flatpak https://en.wikipedia.org/wiki/Flatpak I'm wondering now if Wikipedia would be appropriate to host a linux sandboxed app packaging comparison chart in the form of https://linuxhint.com/snap_vs_flatpak_vs_appimage/ https://linuxhint.com/snap_vs_flatpak_vs_appimage/ - and it would be extensible ...since Wikipedia.
DoofusOfDeath 6y ago
> just use an alternative solution like flatpak Saying "just use an alternative" seems overly dismissive of the complications that entails. IIUC, the only options for that are (a) abandon Ubuntu, or (b) actively circumvent Ubuntu's software distribution infrastructure, reminiscent of dealing with Windows 10 forced updates. IMHO this somewhat erodes Ubuntu's value proposition.
- zentiggr 6y ago
  I have a laptop that I'm planning on rebuilding from a failed NTFS/Win10 system to Linux something. Now I know it's not going to be Ubuntu or anything else derived from Canonical.
  - Endeavourist 6y ago
    Why not EndeavourOS? It's based on Arch Linux, with minimal numbers of external packages; quite unlike Manjaro actually. You can just treat it as a standard Arch install, and even use the ISO to boot with wi-fi drivers and all and install Arch plainly, without the non-wifi and other regrets. EndeavourOS is pretty great; I personally use it as a live-ISO (XFCE environment) and just install Arch from within the live EndeavourOS booted iso. Just throwing it out there.

michaelmrose 6y ago

Sandboxing addresses AN issue but does not address any of the issues discussed in this article. Also sandboxing and running apps under reduced permissions makes a lot of sense but should be seen as a tool to increase security not an answer outright as poorly used any tool can be less effective or even harmful. Historically locking down increasingly effectively often leads to impeding things the user actually wants to do which leads to apps asking for and granting permissions with the net effect of training users click yes to enable whatever the app wants to do. It ends up being not just a technical challenge but a psychological one as well and its less easily resolved once you start having to deal with real users.

blablabla123 6y ago

It seems to incorporate some novel ideas despite its obvious shortcomings. I also think that so far Linux distributions have done very poorly when it came to cross-distribution/forward/backward compatibility of packages. This is a non-issue for popular Opensource packages since they can be easily packaged by the distributors. But not so popular packages sometimes need to be installed in a hacky way when they are not available for the target distribution. Even worse when dealing with commercial software, it can happen that it degrades with each distribution update. Also I think that probably the package format will improve over time and add additional features, that would allow auditing for instance. Also with proper de-duplication (perhaps even on filesystem level) it should be possible to also deal with waste of space.

ex_amazon_sde 6y ago

You can easily create very strong sandboxes for daemons using unit files and packaging them as native OS packages.