Context: I am using PaloAlto Networks Global Protect to connect to a company VPN. https ://www.paloaltonetworks.com/sase/globalprotect. When connecting, it uses SAML-base authentication, and it generates a file in ~/.GlobalProtect/saml.html, and then calls the default browser to view this page. It is an authentication flow similar to the OAuth2 device-flow, and is used when a program lacks the ability to directly interact with a user, but can provide data for the user to authenticate via another device (or in this case, browser).
Expected Results: Firefox will open the link at file :///home/.../.GlobalProtect/saml.html, allow a login, and then complete authentication.
Actual Results: Firefox displays the message “Access to the file was denied”
Cause of the Issue: Access to files for the Firefox application is controlled by its interface with snap. By default, snap restricts file access to a sandbox directory, but permissions can be expanded using the personal-files interface: https ://snapcraft.io/docs/personal-files-interface. This interface permits access to files in the user’s home directory that begin with a ..
The list of files accessible is controlled by the plug that is defined for the snap that uses a subset of the data accessible via the snap interface. The plug for the firefox snap, named firefox:dot-mozilla-firefox is defined here: https ://github.com/canonical/firefox-snap/blob/stable/snapcraft.yaml#L109. This configuration allows access only to the ~/.mozilla/firefox directory.
Because the directory ~/.GlobalProtect is not in this list, access to the file is not permitted, and the SAML authentication flow fails.
Suggested Solution: Add one of the following capabilities to snap.
Create an interface to define custom plugs for a snap to add to it after it has already been installed. E.g. create a new plug firefox:dot-global-protect with read: [$HOME/.GlobalProtect].
Create an interface to edit existing plugs for a snap. E.g. add a new read entry to the existing plug.
My understanding, perhaps a mistaken assumption, is that the firefox snap maintainers would have no ability to know in advance a full list of potential personal-files that a user would potentially need access to.
However, the ability to dynamically increase the scope of access of a program, after it has been installed, would depend on snap to do, just as one can voluntarily connect or disconnect snap plugs into snap interfaces.
One can think of it as being analogous to the way in which Linux file permissions work. If I run cat on a file, owned by a program-user, and the permissions do not allow cat, executing under my user, to access that file, then it is my responsibility to change the permissions of that file so that cat can print it (or I have to use sudo to change my user to access it).
However, I would not say it would be the responsibility of the developers of cat to change their program, or the responsibility of the package maintainers to change their package, just so that I can access a file on my private machine.
The decision regarding what files are safe vs. not safe to access on a computer is very much one that belongs to the owner of the files, wouldn’t you say? It is in this spirit that I believe it is appropriate that snap permits users to control permissions to files in their home directory.
Oh, then just use ubuntu-bug snapd that should open a launchapd bug (I’m never sure where exactly snapd tracks its bugs, sorry for pointing to the wrong direction initially)