AppArmor is the easy thing to fix and the harder part is the changes needed for snap-confine (which is why a bind mount is suggested as the workaround). I’ve suggested something similar to what you said with snap set system homedirs which would:
add a snippet for snap-confine’s profile to /var/lib/snapd/apparmor/snap-confine/homedirs
add a file to /etc/apparmor.d/tunables/home.d to modify HOMEDIRS
write out something for snap-confine to read to perform the necessary mount for /home into the snap’s mount namespace
OTOH, a sticking point is that snap-confine is working in the mount namespace that is shared across all snap invocations, so a mixed system with /home and /foo/homes needs to be handled (perhaps moving the home part to the per-user portion of the mount namespace? cc @zyga)
@zyga I was wondering, didn’t you consider in the past using a similar technique to the one used in layouts for read-only locations (tmpfs with empty files, which are used by bind mounts), as an alternative to overlayfs?
Dude, /home is NOT the default location and NEVER has been. Your inexperience with Linux/Unix is showing now. It may be the norm now, but I remember having to change it from /var on Irix, Solaris, SunOs… all- distros except Debian and I think RedHat since the 90s, up until Ubuntu came around, after the file system standard was MOSTLY adopted (I think RedHat still uses some variations). So be careful who you think you’re talking to.
Well - I have plenty of time now to waste while snap gets removed. Not like I have anything else to do with my life but troll round the internet trying to find why basic bits of software don’t work.
Basically I don’t know why snap needs to write anything to my home directory at all. I fixed my issue by uninstalling snap and just install my package another way. I know you think they are making things easier but the more stuff you add the more maintenance you will have.
I apologize for being negative but truth is truth. Just my own opinion.
It’s the snaps themselves that need to write into your $HOME. AppArmor can’t give them access if it doesn’t know what folders they’re supposed to be able to access, and they can’t be mounted into the sandbox if there’s nowhere saying where that mount should be.
This has been a mostly solved problem for a few releases now, because you can actually tell snap where alternate homes are located, and it’ll adjust policies accordingly.
Are you aware that every single app that has persistent config options, uses any type of caching or ships with adjustable defaults actually writes to your home dir ?
Non-snaps simply hide their directories in your home from you, snaps do not, so complaining about “apps create data in my home, this is why i removed the complete packaging system for them” with a footstomp is rather ironic…
I just got bitten today. firefox does not start from the command line. So much for “user experience”.
Seriously: there is gotta be another way than hardcoding /home/sweethome. And no. I do not find the workarounds feasible or the reasons why you cannot just get the $HOME from the system and trust it, convincing.
Apologies for the bluntness, but please fix it, following the principle of “least surprise” for the user.
Have you opened an issue/bug for this ? It is clearly unexpected and works for everyone else, so it would be good to debug it properly…
There is no hardcoding anywhere, please keep in mind that many enterprise admins actually explicitly disable the home interface to protect their data from possible browser security issues. In that scenario the $HOME/snap directory is the only way for apps to store any data on disk
The policy is applied before any user has logged in and there is no $HOME variable when the system is in that early state. Only one policy can be live at once, and multiple users can sometimes use the same machine. What should snap do if one user on a shared machine sets $HOME to a completely different place to someone else, who do we decide gets to break who?
I just followed this thread looking for a solution. I am running a lab machine with a pretty vanilla Ubuntu version (I use snap because Ubuntu is veeeeeeeeeeeery slow in updating the apt packages).
The snap version I am running is the latest one.
I should not have to jump through hoops because enterprise admins are paranoid. Let me shoot myself in my foot (or other private parts).
Just let the system use $HOME and be done with it. And please… at the cost of sounding whiny and annoying, do not ask me to debug this.
How Vanilla? Cos the Ubuntu default is that $HOME is /home; which is either not the case on your machine or the problem is something else. If you’re not in an enterprise situation, why did this get changed? /home is the FHS spec afterall.
You should avoiding running anything with sudo, snaps or otherwise, unless they actually need it. A significant amount of Firefox’s security model explicitly relies on not being sudo and it actively rejects attempts to use it like this. More snap specific, sudo does not give permissions that sandboxing denies. rm / -rf and sudo / rm -rf should be blocked even by the root user. What can happen though is that random items in your filesystem end up being owned by root instead which then breaks using it at all. E.G., if Firefox creates a new database file but you run it as root - the database is now owned by root, and firefox has no permission to access this under a normal user anymore.
The best move to make now would be to reboot and see if firefox works, if it doesn’t, try purging it entirely (make backups if you have data you want to keep) with sudo snap remove firefox --purge, and then reinstall it with sudo snap install firefox.
