Trying to read the discussion of the snap issue really is hard for me to understand. I’m not able to parse precisely if there’s a “real issue” here or if it’s just “something was hardcoded and it would really just take a small set of commits to resolve this”.
As someone without any sysadmin type experience whose experience is with personal computers, and servers that have basically one or two users plus root, I think I’m missing some context.
Under what circumstances do you want a user’s home directory to not be under /home/?
This kind of workflow is common when you have an infrastructure with many users and many machines, and you want your users to have access to their homedir regardless of which machine they’re logged into.
A typical solution to this is to store home directories on a central file server, and mount the home directories via some network filesystem on each machine. Especially if you have multiple file servers and share users across them, you probably want to mount these somewhere other than /home.
This is a really common pattern on platforms like HPC compute clusters, where many users are running jobs on a shared set of machines.
Funny: I literally did not process “log on” properly, I just assumed it was shorthand for connecting to a particular box with ssh or perhaps using an X11 environment.
I remember going to the computer lab in university and grad school, and logging on to a shared machine. But at the time, I didn’t study CS, and didn’t think about how that was implemented. I treated the machines as analogous to a thin client to my webmail, etc. The idea that I had a home directory there and might keep anything there (as opposed to on my laptop) was quite foreign.
In the cluster usage model, I’ve seen a few different workflows that involved using a web browser to attach to a running job. If the cluster and the user’s desktop aren’t on the same network (or there’s a firewall, etc), then they might want to run a browser on a gateway node that mounts those filesystems. I personally think those workflows are pretty ugly, but they exist.
Another usage model I’ve seen, which came to mind a little later, is “we only have a few very powerful workstations, and many more users”. Think really expensive CAD workstations with multiple GPUs. If you have, say, three workstations and fifteen team members, you might “check out” a workstation to do your really intensive design work but otherwise work on a regular PC. In those cases, you’d also want your home directory when you went over to the workstation, rather than having to haul around USB drives etc.
This is at the University of Toronto, I would assume. So picture thousands of COMPSCI students using Ubuntu workstations around campus to log in and do course work. As a student, you’re not always going to be on the same machine all the time in this environment.
Under what circumstances do you want a user’s home directory to not be under /home/?
If an Unix user entity is used to host some service, not a real end user (say, MediaGoblin) one might want to have its home under /var/lib or even /data/media-goblin. Users aren’t just for end users.
Is there a way to improve startup time for snaps? I’m not particularly concerned with them except for the fact that they’re slow to launch and also print lots on my mount -l
They’re slow to start up? I’ve never noticed that and am curious how you’ve measured that.
That being said the mount issue is real. systemd also generates .mount units for those mounts which end up in /etc/systemd, which in turn means that my etckeeper install gets polluted with a whole lot of total garbage.
It’s visually apparent, but because you asked, I decided to screen record and see if it’s actually the case and it certainly is. Look for yourself. I have only SSDs mounted and these are all on the same drive so I don’t imagine that’s the problem.
These are available on the Ubuntu Software store if you want to replicate.
You can easily download the non-ubuntu chromium binary and install it without need of snap.
I suppose they want to use official packages from a reputable repository. Installing binaries manually really is bad practice for security and maintainability reasons.
Is that a repository, or a single .deb file? If the latter, that doesn’t get updates along with regular system maintenance. If it’s an external repository, that could be a decent solution depending on how much you trust it.
if chromium is anything like regular chrome or firefox they are updated out of cycle with the rest of the system anyway, unless you happen to turn auto-updates off
At work I’m using Chromium and Firefox from the Debian repositories. Auto updates are turned off and will use the standard system update mechanism.
Having random binaries update themselves in a system sounds like a recipe for madness to a sysadmin. Also, how does that even work in a multi-user system where they’re installed system wide? Does that mean these binaries are setuid root or something?
I keep hearing this, but I use jitsi from firefox every day and don’t have any issues. There was a feature missing in firefox about a year ago that was preventing jitsi from working, That was reported and fixed eventually although it took a while to get through the system. Maybe there are still some minor issues but nothing I have seen that makes me want to switch to chrome.
Firefox’s implementation of WebRTC has some issues that make Jitsi scale poorly when anyone in a call is on Firefox. This is fine for small groups; it only becomes an issue if there’s more than 10 or so participants.
I really don’t understand why Ubuntu pushes Snaps when there is Flatpaks (desktop) and Docker (server), unless what they really want is to generate lock in. I wished they were more collaborative and smarter about what maked them stand out (like being a polished desktop Linux). Point 1. was one of the reasons for me to switch to Fedora.
I find the existence of both Flatpak and Snap confusing. They seem to solve a problem that only exists for a limited set of software within an already very limited niche of users. Web browsers on desktop Linux distros seem to be well-served by them, but how many engineer-years have gone into building these things?
I suspect there’s some big benefit/use-case that I’m completely missing.
I find the existence of both Flatpak and Snap confusing.
This!
Snap and flatpack try to solve two completely unrelated problems: application sandboxing and package distribution, and do a notoriously bad job at each one.
Application sandboxing should be an OS-feature, not requiring any action by the potentially hostile application distributors. Thus, it should be able to act upon arbitrary programs. If I want to run “ls” in a controlled container, so be it. Any application, no matter how is it distributed, must be sandboxable.
Package distribution is a different thing. At this point, it seems that nearly all of the problems can be solved by distributing a static executable as a single file.
But it doesn’t need to access to the network, or file contents and it definitely should not be allowed to change anything. Plenty of permissions to restrict.
Can you restrict that on Linux? Is there a separate permission for reading files and reading directories?
So long as the directory has r-x (octal 5) permission, and the file does not have read r permissions you can browse the directory but not read the files contents.
I’m not sure how much more light-weight they can be, given that Flatpak and Snap are both using the same in-kernel container mechanisms (cgroups, namespaces, seccomp etc.) as Docker.
Somewhat tangential (maybe you happen to know, or somebody else who does is reading) – is the sandboxing any good these days, and do Flathub applications/other packagers user them? About two years ago, when Flatpak was just getting hot, the flurry of “this is the future of Linux desktop” posts convinced me to spend a few weekends with it and it was pretty disappointing.
It turned out that virtually all applications on flathub had unrestricted access to the home directory (and many of them had unrestricted access to the whole filesystem), even though it showed the pretty “sandbox” icon – arguably not Flatpak’s fault I guess, but not very useful, and also not very assuring (features that go almost completely unused tend to be broken in all sorts of ways – since no one gets to use them and hit the bugs). Lurking through the bug tracker also painted a pretty terrible picture – obvious bugs, some of which had had serious enough CVEs assigned for months, lingered for months. So basically it was (almost) zero sandboxing done by a system that looked somewhat unlikely to be able to deal with really malicious applications in the first place.
(Edit: I don’t mean that Flatpak, or Snap, are bad as a concept – and I also want to re-emphasize, for anyone reading this in 2020, that all of this was back in 2018 or so. But back then, this looked like years away from being anything near something you’d want to use to protect your data – it wasn’t even beta quality, it was, at best, a reasonable proof of concept.)
Also, even though this was all supposed to “streamline” the distribution process so that users get access to the latest updates and security fixes more quickly, even the most popular packages were hopelessly out of date (as in weeks, or even months) in terms of security fixes. I expect at least this may have changed a bit, given the increase in popularity?
Has any of this stuff changed in the last two years? Should I give it another go this weekend :-) ?
(Edit: I can’t find my notes from back then but trying to google around for some of the bugs led me here: http://flatkill.org/ . There’s a lot of unwarranted snark in there, so take it with a grain of salt, but it matches my recollections pretty well…)
It turned out that virtually all applications on flathub had unrestricted access to the home directory (and many of them had unrestricted access to the whole filesystem),
A cursory GitHub search of the Flathub organization shows ~150-200 applications have --filesystem=host or --filesystem=home each. And close to 100 have --device=all. So it seems that a large portion is still effectively unsandboxed.
Lurking through the bug tracker also painted a pretty terrible picture – obvious bugs, some of which had had serious enough CVEs assigned for months, lingered for months.
This is a disaster in the making. Outside the standard SDKs that are provided through FlatHub, applications compile their own picked versions of… pretty much everything. Just going over a bunch of Flatpaks shows that the dependencies are out of date.
That said, I see what they are aiming for. The broad permissions are caused by several issues that will probably be resolved in time: broad device permissions are often for webcam access, which should be solved by Pipewire and the corresponding portal. The home/host filesystem permissions can partially be attributes to applications which use toolkits for which the portal mechanism isn’t implemented.
The problem that every Flatpak packages their own stuff is more concerning though… I know that the aim is to be distribution-independent, but it seems like a lot could be gained by allowing re-use of regular packages within Flatpaks.
You can easily download the non-ubuntu chromium binary and install it without need of snap.
Then you’re either stuck using PPAs (which is a no-go for certain environments) or manually updating the DEB. Both of which are not good options when it should be as easy getting updates from the official repositories.
You say that but I’d agree it’s a serious bug or even just WTF moment.
Yes, there’s the FHS - but nowhere it says (afaik) that software should break if you change something like this, which isn’t even an edge case but has been done for decades.
I don’t disagree with that. It seems like a poor limitation that deserved more attention from the devs once reported. And it would have likely caused problems at the last place I was a Sysadmin.
What I’m complaining about is the tone with which he’s presented the issue. And it’s not limited to this post; I’ve been reading his blog for about ten years and it’s been a high quality read for most of that time, until relatively recently when the tone has been more entitled and (for want of a better word) whingy which detracts from the substance of what he’s writing about.
From HN:
Now, this is embarassing, here the list of reverse dependencies on snapd:
python3-ubuntu-image xubuntu-desktop xubuntu-core vanilla-gnome-desktop ubuntustudio-desktop-core ubuntustudio-desktop ubuntukylin-desktop ubuntu-unity-desktop ubuntu-snappy-cli ubuntu-snappy ubuntu-mate-desktop ubuntu-mate-core ubuntu-core-launcher ubuntu-budgie-desktop snapd-xdg-open snapcraft snap-confine qml-module-snapd plasma-discover-backend-snap lxd lubuntu-desktop libsnapd-qt1 kubuntu-desktop ember cyphesis-cpp chromium-browser ubuntu-server ubuntu-desktop-minimal ubuntu-desktop ubuntu-core-snapd-units livecd-rootfs maas apparmor libsnapd-glib1 gnome-software-plugin-snap command-not-found
the latest pulseaudio update wants to install snapd
when /home is somewhere else, snaps don’t work - closed with Won’t fix: https://bugs.launchpad.net/snappy/+bug/1620771
Trying to read the discussion of the snap issue really is hard for me to understand. I’m not able to parse precisely if there’s a “real issue” here or if it’s just “something was hardcoded and it would really just take a small set of commits to resolve this”.
In any case yeah hardcoding’s no fun
As someone without any sysadmin type experience whose experience is with personal computers, and servers that have basically one or two users plus root, I think I’m missing some context.
Under what circumstances do you want a user’s home directory to not be under /home/?
This kind of workflow is common when you have an infrastructure with many users and many machines, and you want your users to have access to their homedir regardless of which machine they’re logged into.
A typical solution to this is to store home directories on a central file server, and mount the home directories via some network filesystem on each machine. Especially if you have multiple file servers and share users across them, you probably want to mount these somewhere other than /home.
This is a really common pattern on platforms like HPC compute clusters, where many users are running jobs on a shared set of machines.
Thanks, that’s somewhat helpful, and it’s a world I’m completely unfamiliar with, but what’s the need to run Chromium as themselves on that machine?
Admittedly, I have opened a web browser on a production machine, but I felt that represented that company’s “YOLO” approach to infrastructure.
…what?
These are the workstations the users use. Desktop systems where they do their work. Users usually want or need browsers.
Funny: I literally did not process “log on” properly, I just assumed it was shorthand for connecting to a particular box with ssh or perhaps using an X11 environment.
I remember going to the computer lab in university and grad school, and logging on to a shared machine. But at the time, I didn’t study CS, and didn’t think about how that was implemented. I treated the machines as analogous to a thin client to my webmail, etc. The idea that I had a home directory there and might keep anything there (as opposed to on my laptop) was quite foreign.
Thanks for helping me to connect the dots.
In the cluster usage model, I’ve seen a few different workflows that involved using a web browser to attach to a running job. If the cluster and the user’s desktop aren’t on the same network (or there’s a firewall, etc), then they might want to run a browser on a gateway node that mounts those filesystems. I personally think those workflows are pretty ugly, but they exist.
Another usage model I’ve seen, which came to mind a little later, is “we only have a few very powerful workstations, and many more users”. Think really expensive CAD workstations with multiple GPUs. If you have, say, three workstations and fifteen team members, you might “check out” a workstation to do your really intensive design work but otherwise work on a regular PC. In those cases, you’d also want your home directory when you went over to the workstation, rather than having to haul around USB drives etc.
This is at the University of Toronto, I would assume. So picture thousands of COMPSCI students using Ubuntu workstations around campus to log in and do course work. As a student, you’re not always going to be on the same machine all the time in this environment.
If an Unix user entity is used to host some service, not a real end user (say, MediaGoblin) one might want to have its home under
/var/libor even/data/media-goblin. Users aren’t just for end users.Is there a way to improve startup time for snaps? I’m not particularly concerned with them except for the fact that they’re slow to launch and also print lots on my
mount -lThey’re slow to start up? I’ve never noticed that and am curious how you’ve measured that.
That being said the
mountissue is real. systemd also generates.mountunits for those mounts which end up in/etc/systemd, which in turn means that myetckeeperinstall gets polluted with a whole lot of total garbage.It’s visually apparent, but because you asked, I decided to screen record and see if it’s actually the case and it certainly is. Look for yourself. I have only SSDs mounted and these are all on the same drive so I don’t imagine that’s the problem.
These are available on the Ubuntu Software store if you want to replicate.
As much as I dislike snap, this post is overly dramatic. You can easily download the non-ubuntu chromium binary and install it without need of snap.
The main problems of snap, which are “irreconcilable differences” that will alienate a part of the population, are:
I suppose they want to use official packages from a reputable repository. Installing binaries manually really is bad practice for security and maintainability reasons.
I installed the official chromium .deb for Debian and it works flawlessly. (I prefer firefox, but jitsi does not work well in firefox).
Is that a repository, or a single
.debfile? If the latter, that doesn’t get updates along with regular system maintenance. If it’s an external repository, that could be a decent solution depending on how much you trust it.if chromium is anything like regular chrome or firefox they are updated out of cycle with the rest of the system anyway, unless you happen to turn auto-updates off
At work I’m using Chromium and Firefox from the Debian repositories. Auto updates are turned off and will use the standard system update mechanism.
Having random binaries update themselves in a system sounds like a recipe for madness to a sysadmin. Also, how does that even work in a multi-user system where they’re installed system wide? Does that mean these binaries are setuid root or something?
I keep hearing this, but I use jitsi from firefox every day and don’t have any issues. There was a feature missing in firefox about a year ago that was preventing jitsi from working, That was reported and fixed eventually although it took a while to get through the system. Maybe there are still some minor issues but nothing I have seen that makes me want to switch to chrome.
Firefox’s implementation of WebRTC has some issues that make Jitsi scale poorly when anyone in a call is on Firefox. This is fine for small groups; it only becomes an issue if there’s more than 10 or so participants.
Ok, thanks for clarifying that. I can confirm I am only using it in small groups.
I really don’t understand why Ubuntu pushes Snaps when there is Flatpaks (desktop) and Docker (server), unless what they really want is to generate lock in. I wished they were more collaborative and smarter about what maked them stand out (like being a polished desktop Linux). Point 1. was one of the reasons for me to switch to Fedora.
I find the existence of both Flatpak and Snap confusing. They seem to solve a problem that only exists for a limited set of software within an already very limited niche of users. Web browsers on desktop Linux distros seem to be well-served by them, but how many engineer-years have gone into building these things?
I suspect there’s some big benefit/use-case that I’m completely missing.
This!
Snap and flatpack try to solve two completely unrelated problems: application sandboxing and package distribution, and do a notoriously bad job at each one.
Application sandboxing should be an OS-feature, not requiring any action by the potentially hostile application distributors. Thus, it should be able to act upon arbitrary programs. If I want to run “ls” in a controlled container, so be it. Any application, no matter how is it distributed, must be sandboxable.
Package distribution is a different thing. At this point, it seems that nearly all of the problems can be solved by distributing a static executable as a single file.
That may be rather difficult. It already needs access to the whole filesystem…
But it doesn’t need to access to the network, or file contents and it definitely should not be allowed to change anything. Plenty of permissions to restrict.
Can you restrict that on Linux? Is there a separate permission for reading files and reading directories?
You’d also need a whitelist for reading some files, such as shared libraries and locale.
Well it has to be able to write to stdout… which could be any file descriptor.
So long as the directory has
r-x(octal 5) permission, and the file does not have readrpermissions you can browse the directory but not read the files contents.No I mean is there a way to allow
readdirbut notread? AFAIK Linux does not have that level of granularity.This is entirely new to me too.
From the wikipedia entry https://en.wikipedia.org/wiki/Snappy_(package_manager):
So it’s a more light-weight Docker I guess.
I’m not sure how much more light-weight they can be, given that Flatpak and Snap are both using the same in-kernel container mechanisms (cgroups, namespaces, seccomp etc.) as Docker.
Somewhat tangential (maybe you happen to know, or somebody else who does is reading) – is the sandboxing any good these days, and do Flathub applications/other packagers user them? About two years ago, when Flatpak was just getting hot, the flurry of “this is the future of Linux desktop” posts convinced me to spend a few weekends with it and it was pretty disappointing.
It turned out that virtually all applications on flathub had unrestricted access to the home directory (and many of them had unrestricted access to the whole filesystem), even though it showed the pretty “sandbox” icon – arguably not Flatpak’s fault I guess, but not very useful, and also not very assuring (features that go almost completely unused tend to be broken in all sorts of ways – since no one gets to use them and hit the bugs). Lurking through the bug tracker also painted a pretty terrible picture – obvious bugs, some of which had had serious enough CVEs assigned for months, lingered for months. So basically it was (almost) zero sandboxing done by a system that looked somewhat unlikely to be able to deal with really malicious applications in the first place.
(Edit: I don’t mean that Flatpak, or Snap, are bad as a concept – and I also want to re-emphasize, for anyone reading this in 2020, that all of this was back in 2018 or so. But back then, this looked like years away from being anything near something you’d want to use to protect your data – it wasn’t even beta quality, it was, at best, a reasonable proof of concept.)
Also, even though this was all supposed to “streamline” the distribution process so that users get access to the latest updates and security fixes more quickly, even the most popular packages were hopelessly out of date (as in weeks, or even months) in terms of security fixes. I expect at least this may have changed a bit, given the increase in popularity?
Has any of this stuff changed in the last two years? Should I give it another go this weekend :-) ?
(Edit: I can’t find my notes from back then but trying to google around for some of the bugs led me here: http://flatkill.org/ . There’s a lot of unwarranted snark in there, so take it with a grain of salt, but it matches my recollections pretty well…)
A cursory GitHub search of the Flathub organization shows ~150-200 applications have
--filesystem=hostor--filesystem=homeeach. And close to 100 have--device=all. So it seems that a large portion is still effectively unsandboxed.This is a disaster in the making. Outside the standard SDKs that are provided through FlatHub, applications compile their own picked versions of… pretty much everything. Just going over a bunch of Flatpaks shows that the dependencies are out of date.
That said, I see what they are aiming for. The broad permissions are caused by several issues that will probably be resolved in time: broad device permissions are often for webcam access, which should be solved by Pipewire and the corresponding portal. The
home/hostfilesystem permissions can partially be attributes to applications which use toolkits for which the portal mechanism isn’t implemented.The problem that every Flatpak packages their own stuff is more concerning though… I know that the aim is to be distribution-independent, but it seems like a lot could be gained by allowing re-use of regular packages within Flatpaks.
I’m thinking more lightweight conceptually. Docker is seen as a sysadmin/devops thing, Snappy is more like a mobile app.
In practice however it is still a sysadmin thing.
Then you’re either stuck using PPAs (which is a no-go for certain environments) or manually updating the DEB. Both of which are not good options when it should be as easy getting updates from the official repositories.
I’ve found Chris’ recent posts to be increasingly histrionic. He’s otherwise been a reliable read for ages.
You say that but I’d agree it’s a serious bug or even just WTF moment.
Yes, there’s the FHS - but nowhere it says (afaik) that software should break if you change something like this, which isn’t even an edge case but has been done for decades.
I don’t disagree with that. It seems like a poor limitation that deserved more attention from the devs once reported. And it would have likely caused problems at the last place I was a Sysadmin.
What I’m complaining about is the tone with which he’s presented the issue. And it’s not limited to this post; I’ve been reading his blog for about ten years and it’s been a high quality read for most of that time, until relatively recently when the tone has been more entitled and (for want of a better word) whingy which detracts from the substance of what he’s writing about.