New to Linux, I'm guessing I'm dealing with an app permissions type issue.
I'm sure it's a user error and not actual bug..
Sometimes when I save a file from a program, it only offers certain file locations, ie I can see computer/home/[username] but nothing else (documents, downloads, etc. don't show up) Also, if I save a file in that location I cannot see it in file explorer, and if I follow the same file path in file explorer thats where Docs, downloads, pictures, etc is located.
I have run into this in multiple programs, but the current one is proton pass, trying to import a .csv from previous password manager.
I'm sure it's something simple I don't know but it sure has me frustrated!! Any help?
ProtonPass exists as a .deb or a .rpm for its standalone manager, but also as a browser plugin. If your web browser is a Flatpak, the problem you're having sounds to me like the flatpak has access to your home directory, but not access to its subdirectories. Can you confirm if you're trying to use the browser plugin, and if so, if your browser is a flatpak?
If you're trying to use the standalone .deb installation, the above shouldn't apply.
Thanks to Locklear for getting be barking up the right tree.
I uninstalled snap version, installed flatpak version, and edited permissions in flatseal to include 'All User Files'
This fixed the issue after a reboot.
As I'm also new to concept of snap/flatpak and flatseal - can anyone confirm that this is NOT the same as giving root access or allowing unreasonable access to the app for what I'm trying to accomplish?
Using only .deb packages, the system is sandboxed. This isolates the root system from potential security holes. Flatpak and Snap are sandboxed as well, which creates a Double Sandbox.
It truly boggles my mind that so many package maintainers offer Snap or Flatpak versions when they know that the app will need access to either the user folders or to the system in order to work or to work properly.
Never having prepared a Linux package of any sort, is it possible to set permissions on a snap or flatpak such that it installs with what the end user will need? For comparison, APKs have locked down permissions as well, but rather than having to download an additional tool and make manual adjustments, the user can see which privileges are required before installation and must allow certain things. (This is why one generally has to allow notifications on a per-app basis.)
As Aravisian said, no. "All user files" should mean your /home/ and everything under your /home/, and nothing else. You might want to be more careful/precise if you mount a drive under your home directory, though, as I once deleted something on an entirely different SSD because I mounted /dev/nvme0n1p1/bottles as ~/bottles. If you have a mount point under your home directory, you MIGHT be giving it access to whatever's under that mount.
If you're new to containerized apps in Linux, I strongly suggest you give this explainer a look. It's a bit long, but there are pros and cons to the package types available in Linux, and you'll be doing yourself a disservice not to know about them. On this forum, the strong recommendation is to use .deb packages whenever possible. Many users reject snap and flatpak entirely, going so far as to remove support for them from their system. There's also a third containerized app package called AppImage, as well as a few others that don't apply to Zorin, but are covered in the video.
As a Zorin user, you'll want to be aware of .deb, snap, flatpak, and appimage.
The short answer is yes, using finish-args in the Flatpak builder - which is why you can instruct using flatpak --override commands (this also means that Flatseal is a handy GUI front end, not necessary to change Flatpak permissions.)
With Snaps, it is less straight forward and more restrictive. It is not as configurable as Flatpak is - but it is moderately present.
So... as you point out the developers could - why don't they?
I chalk this up to a basic Two:
A disconnect between developer desires and user expectations: The developer does not fully grasp, nor care to grasp, the users actual method of using the application.
Legacy practices being ignored by developers: Many access points will need portals to properly function and the developers default to the thinking of "Least Access is better" in order to meet demands from higher up for demonstrating "better security using our method" than to actual use cases.
So, either they are disconnected from their user base or they are more intent on Proving Security than they are Functionality.
I do not see this situation improving any time soon. The End User is not the target audience to make happy - because we are not the ones making the payments. Corporate interests take priority. This is why "Free" means Freedom not "Free Cost" and why GnuLinux users need to begin letting go of the "free cost" demand and retake control of the developmental direction.
Yes, my wording could have been better - but you get the idea.
They restrict harshly, rather than logically.
That being said...
"Least access is better" as a principle must be weighed against my earlier comment about it creating a Double Sandbox. So, if something is already restricting root from user actions; then the additional restriction put in place by the second sandbox becomes redundant, not necessarily "better" security.
In relation to my statement that least access is better, inability to access is inability to access, whether it's restricted once or twice, unless the second time is liable to cause problems (such as accidentally hardware muting and software muting oneself on a video call, then not realizing both are on when it's time to talk). As long as functionality isn't impaired, I don't see a problem with double sandboxing. If it is, then yes, it's a problem.
Being generous, I'd assume the intention is to allow the user control over the sandbox in ways a .deb doesn't have. This could be a matter of my inexperience, but I'm not aware of a way to restrict a .deb beyond restricting the user. If for some reason I want my photo viewer to have access to /home/Pictures/stuff and not /home/Pictures/otherstuff, I know how to do that with a flatpak, and don't with a .deb, other than removing my own rights to the directory.
