1768303 - Firefox snap version on Ubuntu 22.04 is unable to read local documentation

Status: RESOLVED FIXED

(Firefox Build System :: Third Party Packaging, defect, P4)

Description

[zingam]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

I am trying to use Rusts' rustup doc command to read documentation but Firefox is unable to access it:

https://github.com/rust-lang/rust/issues/61796

It looks this issue is related to the snap package settings.

Actual results:

Access to the file was denied

The file at /home/isto/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html is not readable.

It may have been removed, moved, or file permissions may be preventing access.

Expected results:

I expect that I can use Firefox to read local documentation/HTML in whatever directory it is.

Comment 1

[zingam]

Attachment: Screenshot on 2022-05-13 at 20:14:41.png

Comment 2

[zingam]

Is there a workaround for this except installing an alternative browser?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Use an official build from https://www.mozilla.org/en-US/firefox/new/ rather than a snap, probably

Comment 4

[:gerard-majax]

(In reply to zingam from comment #2)

Is there a workaround for this except installing an alternative browser?

As much as I can tell, $HOME access is granted except for . folders. This is a Snap sandboxing limitation.

Comment 5

[:gerard-majax]

Olivier, I've learnt about this https://forum.snapcraft.io/t/the-personal-files-interface/9357 but I worry this is not really going to scale. Given this current bug is about rust doc, maybe we could still have that interface implemented for a few well-known directories like this ?

Comment 6

[Olivier Tilloy]

I think the system-packages-doc interface is better suited for this.
This doesn't scale any better though, unfortunately.

As a workaround, try bind-mounting ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/ to e.g. ~/rust-doc. That folder should be accessible in firefox packaged as a snap.

Comment 7

[Negritas Sergiu, Desktop QA]

Hello! I have tried to reproduce the issue with firefox 107.0a1(2022-10-14) on Ubuntu 22.04, unfortunately I wasn't able to reproduce it. Could you please answer the following questions in order to further investigate this issue.

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed if so can you list them?

Comment 8

[Damian Yerrick]

I found another manifestation of this sandbox misfeature related to Wine applications' release notes. When OpenMPT is installed in Wine, it attempts to open an HTML document containing release notes in the default browser. Snap confinement blocks Firefox from reading files in the hidden folder containing the Wine C drive.

environment: Firefox 107.0 (64-bit) Snap on Xubuntu 22.04 LTS

steps:

1. Install Wine
2. Install OpenMPT https://openmpt.org/
3. At the end of the install wizard, ensure that view release notes is checked

expected: release notes appear

actual: an error page

Access to the file was denied

The file at /home/pino/.wine/drive_c/Program Files/OpenMPT/Release Notes.html is not readable.

• It may have been removed, moved, or file permissions may be preventing access.

Comment 9

[Damian Yerrick]

I performed these steps to confirm that the edge channel Snap package shows a behavior difference between loading the same file from within ~/.wine and a non-hidden folder.

1. sudo snap refresh --edge firefox
2. firefox --version returned Mozilla Firefox 109.0a1
3. firefox about:profiles and create a brand new profile
4. Verify that no extensions are installed in this new profile
5. Attempt to view /home/pino/.wine/drive_c/Program Files/OpenMPT/Release Notes.html - "Access to the file was denied"
6. Copy the file to the desktop and view /home/pino/Desktop/Release Notes.html - loads as expected
7. Attempt to revert my changes (sudo snap refresh --stable firefox)
8. Be notified that my primary profile has been silently and irreversibly upgraded, then race against the clock to sign into webmail within five minutes after signing into Firefox Sync

Comment 10

[:gerard-majax]

Amin, the more I look at that, the more I think that maybe the correct fix would be similar to bug 1800350

Comment 11

[Amin Bandali [:bandali]]

Right, I believe blocking access to hidden files is indeed the intended behaviour with snap sandboxing; I'm not entirely sure what would be the best course of action here. Seb?

Comment 12

[seb128]

Right, that's by design. We can continue whitelisted known directories as pointed out before but a real solution would rely be provided either by going through portals to open files or it might be solved by the apparmor prompting work when that is ready

Comment 14

[:gerard-majax]

Merged and will get fixed when snapd 2.62 gets released: https://github.com/snapcore/snapd/pull/13130