Ubuntu
firefox package

firefox snap unable to open files from file-roller

Bug #1968548 reported by Valentijn Sessink on 2022-04-11

This bug affects 1 person

	Status	Importance	Assigned to
snapd	In Progress	Undecided	Unassigned
file-roller (Ubuntu)	Confirmed	Undecided	Unassigned
firefox (Ubuntu)	Confirmed	Medium	Unassigned

Bug Description

Due to Firefox Snap being contained and not being able to read in ~/.cache/, html-files from an archive cannot be read with Firefox. Ubuntu 22.04 Jammy Jellyfish

Steps to reproduce:
- open, with file-roller, an archive containing a HTML-file;
- double click (i.e. open) the archived HTML-file (with file-roller)
Now file-roller extracts this to ~/.cache/.$randomname/file.html and tells (through xdg-open? Dunno...) firefox to open it.

Expected result: Firefox shows file
Actual result: "Firefox says: Access to the file was denied

The file at [$HOME]/.cache/.fr-KMCDMo/file.html is not readable.

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

This is basically a different manifestation of bug #1959417 but I'm filing it separately because it is a separate problem.

See original description

Tags:

Revision history for this message

Valentijn Sessink (valentijn) wrote on 2022-04-11:

Example gz-file to demonstrate. Edit (152 bytes, text/html)

description:

updated

madbiologist (me-again) on 2022-06-02

tags:

added: jammy

Revision history for this message

Olivier Tilloy (osomon) wrote on 2022-06-03:

Indeed, by default file-roller will temporarily unpack files in the user's cache folder (it can in some cases fall back to the user's home directory, or a temporary directory, see https://gitlab.gnome.org/GNOME/file-roller/-/blob/master/src/file-utils.c#L55).

Given this, I wonder whether it would be acceptable to allow firefox (and other browser snaps) to read files under @{HOME}/.cache/fr-*/, by amending an existing snapd interface.

Or could file-roller be patched to use the OpenFile method of the FileChooser portal (https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-FileChooser.OpenFile)? Would you mind filing a file-roller bug at https://gitlab.gnome.org/GNOME/file-roller/-/issues to request this, and link back to it here?

Changed in firefox (Ubuntu):
status:	New → Confirmed
tags:	added: snap
Changed in firefox (Ubuntu):
importance:	Undecided → Medium
summary:	- firefox unable to open files from file-roller + firefox snap unable to open files from file-roller
Changed in file-roller (Ubuntu):
status:	New → Confirmed

Revision history for this message

Valentijn Sessink (valentijn) wrote on 2022-06-16:

Hi, if I understand correctly, you're asking me to file a bug in file-roller. Unfortunately I don't know what "the FileChooser portal" is, nor do I know why it would be advantageous for file-roller to implement it. Now it could be that this actually *is* a Good Thing; but then I'm probably still not the one to file this bug. I simply cannot think of a reason to patch file-roller because Firefox Snap refuses to open certain files.

In a more general sense: if reading and/or writing files under $HOME/.cache/ is discouraged or otherwise undesirable, then that should be targeted - I'm guessing a whole lot of bugs must be filed then, but this very bug can be closed. However, if $HOME/.cache/ is the right place to cache these things, then Firefox Snap should be patched.

Revision history for this message

Olivier Tilloy (osomon) wrote on 2022-06-16:

Well, I personally think that $HOME/.cache isn't the right place to unpack temporary files, those should probably be unpacked somewhere under $TMPDIR by default. But that wouldn't really solve this bug, because the firefox snap, being strictly confined, would still be unable to read these files. And there might actually be a good reason for file-roller to unpack files under $HOME/.cache/ that I'm not aware of.

Thinking about it again, I'm not sure that the OpenFile method of the FileChooser portal would be of any help here. It's firefox that is sandboxed, not file-roller.

Revision history for this message

Olivier Tilloy (osomon) wrote on 2022-06-16:

Following my own suggestion, I submitted https://github.com/snapcore/snapd/pull/11892.