Hi,
I’ve just installed FF 94 on an UbuntuBudgie 20.04 and I am very surprised it has by default access to /tmp and other folders at root file system.
I can’t use any-every-thing from root file system according to rights and permissions.
I guess it’s thanks to ( right part of the image ) :
but is it expected and safe ?Hence my uneducated question in title.
( + that comment on the left part of picture suggesting there is no AppArmor profile for Firefox ? )
Yes. It has defined the two super-privileged interfaces “system-files” and “private-files”, where it declares that it needs access to certain specified locations outside of normal confinement. Snaps that declares these interfaces must be manually reviewed.
The dot-mozilla-firefox plug using the personal-files interface, allows Firefox to access $HOME/.mozilla/firefox, which would normally be inaccessible because it is a hidden folder at your home root. The etc-firefox-policies plug, using the system-files interface, allows Firefox to access /etc/firefox/policies.
So yes, it is both expected and safe and it is still confined. If it had been true that there was no AppArmor profile for Firefox, then you would’ve been able to access any-everything from root, so that’s clearly not the case.
Thanks for explanations.
If I understand right, since Firefox-snap runs as my $USER, it can’t do « more » than what my $USER can ?
Any way to list which folders firefox-snap has access to ?
As explained by @joerlend.schinstad, the Firefox snap is indeed confined, and it does have a couple of exceptions in place to enable read-access to $HOME/.mozilla/firefox for initial profile import, and /etc/firefox/policies.
The snap also plugs the home interface, which allows read/write access to everything that’s not hidden files and folders in your home directory.
As far as I know there is no easy way to list all folders a snap can read/write, but the snap connections SNAPNAME command will tell you which interfaces are connected, and all the interfaces are documented here.
For a more detailed insight into the permissions, you can inspect the generated apparmor profile. For firefox it lives at /var/lib/snapd/apparmor/profiles/snap.firefox.firefox.
Last but not least, you can run a shell into the snap’s namespace and use ls / stat commands to inspect what’s readable and what isn’t: snap run --shell firefox.
Thanks again.
Chromium has the same « system files » interface connected though it does not have exactly access to same files and folders as Firefox : what does it depend on ? ( it seems FF has access to much more things ).
What if I disconnect that interface in Firefox, which features or usage may I lose ? ( Let’s say I’d disconnect this interface later after a first run of the snap ).
I confess : here I need explanation for noob.
I’m going to take a guess that OP is referring to the XDG desktop portal allowing access into the host file system.
When you use the graphical interface to open and save files, the graphical interface runs outside the snap itself. It only opens the file/folders specifically requested by the user.
While the interfaces above do give access to some areas most snaps wouldn’t have access to, they don’t give unrestricted access to the system.
As a comparison, try access file:///tmp in the Firefox snap itself (i.e, as an URI in the address bar), you’ll see that actually it isn’t the systems normal /tmp folder, and Firefox doesn’t have access to /tmp. The file chooser GUI does.
If you use the GUI to access a file that Firefox can’t usually access, it’ll appear in /run/user/$UID/doc/example/example2, not /tmp.
If you disconnected the system-files interface, I don’t think anything would happen. You’d find the GUI picker works the same way, but Firefox would be unable to access policy configuration in /etc. This is more useful for enterprise users than normal home users so any specific home user is unlikely to notice it IMO.
The relevant portals functionality is a subset of the desktop interface. If you disabled that interface you’d almost certainly cause a lot of problems with the snap.
However everything under the desktop interface is considered safe by design, so there’s nothing to worry about.
I think that was a good guess, thanks ( again ).
This « As a comparison, try access file:///tmp in the Firefox snap itself… » and that « use the GUI to access a file (…) it’ll appear in /run/user/$UID/doc/example/example2, not /tmp » helped me get a clearer picture.
Hence the word « interface » after all : interfaces are the filtering bridges between the snap-app itself and the other « app » outside of the snap. Here Firefox is the snap, the file-picker is not « in » the snap, the « system files interface » will only send the picked file to the snap.
Sorry for re-phrasing but when I try to help on ubuntu-forum-fr, I like sometimes to explain by « analogy ». But to build a relevant analogy, I have to understand myself the core principle… and turn it into french. [ and I am not a dev’ - just an user, at home and at work ]
So is the « filtering bridge » a good picture in that case, or « filtration barrier » ? 
Anyway ( initial ) case closed and all answers here are part of the solution so I just modified the discussion title.
you are mixing portals and interfaces … an interface gives the app direct low-level access, the system-files interface here simply allows that the FF binary can copy configs from $HOME/.mozilla/firefox to $SNAP/.mozilla/firefox on first start to have access to the existing config files … the later is the per-application home dir that snap packages use by default.
this has nothing to do with accessing files through the file-picker gui …
recent implementations of toolkits like Qt and GTK ship with a “portal” implementation that can be used by any confined app (snap or flatpak) by simply setting certain environment variables. these portals mimic actual access to the file system to the end user but in reality they copy (or hard-link) the files around from their original location into a place inside the confined application space … in case of i.e. editing a file the modified file will be copied back to its original location afterwards.
the quality and feature-set of these portals completely depend on the host system an the version of the toolkit that is installed there (the portal implementation on 16.04 was way behind what you find on 20.04 and will likely have a lot less features, snaps using portals will behave different on either of these releases in the event of opening a file through a portal)
so the portal access to files has nothing to do with interfaces and is not specific to the package mechanism either (it works the same on snap and flatpak apps) but is simply provided as part of the toolkit on the host.
Errrr… yes you’re right, that’s why I ask explanations 
It may be obvious for you ( you as an ensemble - snapcrafters, dev’, people who daily deal with the « inside » of snap ) but that’s not for « normal » users who sooner or later have to face some bits of these new ways.
So… in this example Firefox-snap + file-picker. I can access and browse file through file-picker into /tmp or /etc or /var and many else. Is this expected ? And what / who limits this access ?
I want to be clear in my mind for myself and be able to explain what happens to other people like me, uneducated and stupid 
This is why i tried to explain it
your filesystem permissions …
a portal should (not sure they already do for everything, i’m not much in the portal business) allow the user to open any file she can access by normal filesystem policies of the host …
… under the hood it is just doing cp <sourcefile> <some place the app can access> … in the UI it is faking the place of <sourcefile> so you as user think you are visually accessing a file in /tmp, /var, /etc while the app under the hood “physically” accesses it in /tmp/snap.firefox/tmp
