Interesting idea - - - thanks.
Except - - - - I haven’t been running said server because I couldn’t count on it. (Tools that other people control don’t last very long for me - - - - I do remember the slogan from early microcomputing - - - - computing your way - - - implying that the IT center did NOT have control.)
I haven’t had the time required to go through all the steps that are required to purge that system from all aspects of the snapd/lxd combination that I had used - - - - and yes it wasn’t even possible to remove files/directories using rm -r.
So my efforts after I choose to restart the system will likely have a different focus.
When I did mention the issue after the second system take down the comment was interestingly denigrative and quite convinced me that expecting any positive change was likely futile.
I continue to follow this particular thread because I thought that lxd had the possibility to be an excellent product but as said product was permanently tied to snapd - - – well one can only hope.
Interesting idea - - - thanks.
- Frequent updates are the teeniest, tiniest, tip of computer security.
- The difference between automatic updates and frequent manual updates is indistinguishable.
- Any form of updates should NOT reduce security (I provided such a use case at-least twice).
- The Linux/FOSS way is to put users in control.
- Rather than use cron (or friends), the devs reinvented the wheel. These last two points are the sole reason this thread exists.
If security is really the issue, then I would have expected Canonical to:
- Put IDS front and center by building in any of OSSEC, AIDE, etc.
- Have an installer option for a bastion server (e.g., central log server, OSSEC server, etc.).
- Integrate IDS and automatic updates. (Again, that was my suggestion.)
- Put substantial effort toward AppArmor profiles.
- On and on…
Now, don’t get me wrong, read-only filesystems and atomic updates are nice. However, there are a number of existing projects to which Canonical could contribute. Frankly, just containerizing web browsers, would have a larger security impact.
Also, I want to second @dabeegmon on “the comment was interestingly denigrative and quite convinced me…” I made a simple and constructive suggestion that was twice blown-off; otherwise, from my perspective, all I see is push-back. I came to this thread because I wanted to try Ubuntu for some IoT work, which snaps are a critical part of the Ubuntu solution. Instead, I have been “quite convinced” to stick with Debian and not use snaps. I hate say it, but this thread “feels” like snaps are headed in the same direction as mir, etc.
This is because the devs have a vision and they actually have no obligation to fold to users on this issue, it’s their software, you don’t have to use it. I’m pushing back because I’m trying to make progress by giving responses that I think knock down suggestions that the devs have already signaled they’re aware of and have rejected, I want to try and encourage both users and the devs to keep this thread open and keep talking in the hope that more refinement of the status quo can be found (or even overturning the status quo if people can give enough hard use cases that are not covered by existing solutions devised by the devs and for which the devs can’t find adequate solutions in the future). I’m sorry if people have found my comments unhelpful but I’m trying to help you write responses which the devs will find useful. In @dabeegmon’s case I really, really think that the devs will need logs (because dabeegmon’s explanation of their situation could be wrong and I don’t see why the devs should fold their position based on an issue reported by just one person and without adequate evidence to back it up) and I’m more than happy to help dabeegmon to find them.
If you’d rather I just shut up and let the devs get annoyed with the responses (if they read them at all), answer angrily (if at all), and close the thread, thus shutting down all criticism and hope of change in the future, then I can do so, if you think that would be more helpful.
What I’m finding really fascinating in the very long chain is the polarization.
@Ads20000 This is because the devs have a vision and they actually have no obligation to fold to users on this issue, it’s their software, you don’t have to use it.
@tony The Linux/FOSS way is to put users in control.
>Rather than use cron (or friends), the devs reinvented the wheel.
When I read this - - - - I understand one thing - - - - - an incredible polarization.
Now there has been talk of accommodation but if anything even that has largely diminished.
Another interesting point (scrolling back about 10 months in total) is that it would appear that the dev community might read any posting here but that they are no longer responding. This lack of responses further buttresses the understanding that there are some strict orders NOT to engage further. (Interesting that!)
Philosophically there have been quite a number of arguments presented here as to why the ‘vision’ as you have termed it really isn’t getting the traction expected from the dev team.
My thinking is that there is presently a market for this from those that aren’t worried about the issues that have been raised (over and over again) and from corporate embedded system development (a part of IoT) where it will be locked into a ‘do not upgrade’ setup because corporate doesn’t want the headache of dealing with upgrade issues from users.
The likelihood of me actually uploading the many pages of logs needed for anyone to exactly ascertain the cause of my system shutting itself down 4 consecutive months after I added a firewall rule disallowing access to revisions - - - - well its quite low. Why you ask - - - - my ability to trust this process has been very badly bruised - - - - I followed directions and dev team suggestions - - - - - and I got something that I didn’t want - - - - something I can’t even remove (except with a fairly complicated multi-step process) that I haven’t taken the time to work on because I use computers as tools to do other things and I just haven’t had time to battle with something that is going to be a time sink hole.
You do not need to ‘upload … many pages of logs’, just journalctl for the time that your computer shut down. If you are unable to provide this then the developers cannot have any way of working out what your issue is for themselves.
This is for 2 reasons. One is that all non-classic snaps are already confined by AppArmor which denies access to things like /etc, /root, your home folder, etc. without an appropriate interface connected. Secondly, there is upcoming working on supporting portals that will allow a snap to attempt to access any file on the system and display a graphical prompt allowing you to allow that access. I’m not super familiar with how portals are implemented, but I know that work is underway and it will be the preferred way to provide snaps access to files going forward after it’s done as it does exactly what you want and provides the user a way to control what files are accessed by snaps as those files are attempted to be accessed. Of course not every snap will implement support for portals, but then it’s an adoption question.
Non-classic snaps are not allowed to read/write to any file in the home directory starting with a dot. 
Additionally, even if you do use a classic snap, you need to explicitly acknowledge you are installing a classic snap with the
--classic flag, and only developers that have been vetted are allowed to publish classic snaps.
The gnome-calculator snap (and to my knowledge all other pre-installed snaps) are all strictly confined (i.e. not classic) and hence are sandboxed by the snap confinement model detailed in this white paper. This means that they cannot access things like arbitrary files on the filesystem and also cannot arbitrarily access devices on the system, in the way I presume a keylogger would.
 These interfaces could be auto-connected however if a snap author requested auto-connection as per the snap declaration approval process
 Though now they can if the snap is vetted using the snap interface auto-connection approval process and uses the personal-files interface new in 2.37.
Why don’t you just let this portion of your user base disable this thing? Your stance towards your users is we know better than you. This is wrong. Let most of your users use what you find appropriate, but please, let us who understand our OS configure snap according to our needs.
On updates, this is basically their position (though they will try to deny it, because the optics aren’t good, but I still think this is basically what the argument boils down to), and their argument, they claim, is backed up by evidence of a great many people remaining on outdated and unsafe software when they have the option to. How do you back up your claim that ‘This is wrong’? Just that Linux is about choice and control? But it’s just free software and snappy is free software (aside from the store code) and can be forked (and/or someone can set up an open-source store) if people really don’t like this decision (but no-one has yet)?
Our devices disable the autorefresh from store, but our developers make ti automatic to update our software , now we recieve a bill show that we need to pay about 6k dollar for 4G data of 300 devices of one mouth.
How do you back up your claim that ‘This is wrong’?
Easily. You worry about outdated and unsafe software. But no one in this thread have ever asked for disabling automatic updates by default. What is desired is ability to switch it off.
But it’s just free software and snappy is free software (aside from the store code) and can be forked (and/or someone can set up an open-source store) if people really don’t like this decision (but no-one has yet)
You are right. I don’t want any forced babysitting. I’ve used snap only to get LXD on Arch, but I’m now on AUR package. I’d gladly see more diversity in package/software managers, but this is just another App Store, not respecting what user wants.
I understand that, so what, exactly, is wrong about the snappy developers not providing a simple, global, off switch for automatic updates? Is your argument that it is wrong sound?
No worries, if you can’t deal with the status quo on this issue then that is the correct action to take ‘not respecting what user wants’ isn’t that true of every piece of software, though, because no piece of software has an infinite number of toggles so that the user can tweak the software to do exactly what they want it to do?
Your response would seem as if it were written by someone who hadn’t actually read through the rather voluminous previous parts to this conversation.
@marekhwd What is desired is ability to switch it off.
@Ads20000 I understand that, so what, exactly, is wrong about the snappy developers not providing a simple, global, off >switch for automatic updates? Is your argument that it is wrong sound?
The answer to your first question lies in the many requests from other long term devs on other projects that have advanced quite a few reasons - - - none of which trump management decisions.
Your second question shows faulty logic. You don’t even say that the argument is wrong and you present no reasons - - - - just by your position (which is really not clear that it is anything official) you state that the argument is wrong.
@Ads20000 No worries, if you can’t deal with the status quo on this issue then that is the correct action to >take ￼ ‘not >respecting what user wants’ isn’t that true of every piece of software, though, because no piece of >software >has an infinite number of toggles so that the user can tweak the software to do exactly what they >want it to do?
Your posit here is actually quite amusing. Somehow you are suggesting that every piece of software is infinite. Would love to hear your argument for that - - - but - - - as that posit is quite patently false the requester’s ask for a toggle is not negated.
I’m locking this thread for a while. Please be nice to each other. It’s possible to disagree with people’s opinions without being disagreeable.
I live in a very poor country, I have a mobile data connection which is very very expensive and limited. I just installed Ubuntu 18.04 and almost instantaneously I was shocked because snapd was consuming all my data plan. So my question is, can I stop snapd from eating my data connection?
I am trying to be very polite, but honestly after reading this thread I am feeling very frustrated about the way this issue had been handled by the dev team. I am in a huge need for a definite solution and not just a temporal one. Do I need to remove snapd from my system?
This has been covered in this topic and the one about metered connections:
In 18.04, in the network settings, make sure you’ve told it that the network is metered.
Then, tell snapd to not refresh on metered, via
snap set system refresh.metered=hold.
Thanks for the quick response. However if I understand correctly. the above is not going to stop snapd for automatically update it self in the long run? Is this true?
yes, of course. It gives you control over when that update happens (you can also change the refresh frequency, if you’re never not metered for example maybe it’d be best if you just set the refresh to be every 2 months or something).
Ok, thanks again for the quick reply, best!