1780379 - Using /dev/shm as via XDG Document Portal results in EACCES when writing files

Status: REOPENED

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

Description

[David Kra]

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

Steps to reproduce:

Three settings ignored: Download directory, ask where to download, and cache directory.

Download Directory and ask where:

Using the about:preferences UI:
Change the download destination to /dev/shm or to /run/shm.
Uncheck "Always ask you where to save files".
Close the preferences page
Open another page. Hit <ctrl>s to save it.
Notice that the save-to dialog opens up. That should not happen.
Notice where it defaults to as the destination does not match the preference.
Save the page.
Look for the page where firefox said it would be saved, and in /dev/shm, and /run/shm.

Also, look at your equivalent to my /home/dakra/snap/firefox/common/.mozilla/firefox/tbzkkivl.default/prefs.js
Mine shows, in part:
user_pref("browser.download.dir", "/run/shm");
user_pref("browser.download.folderList", 2);
user_pref("browser.download.lastDir", "/run/user/1000/doc/aabdd296");
user_pref("browser.download.panel.shown", true);

Cache Directory:
In pref.js, change the cache directory, e.g.
user_pref("browser.cache.disk.parent_directory", "/dev/shm/firefox-browser.cache.disk.parent_directory");
The change is ignored.

Actual results:

Downloads: The Save to pop-up dialog is displayed. The default location does not match the settings.
Cache: The cache setting is ignored.

Expected results:

The download goes to the download destination as specified in the settings, without a pop-up dialog.

The recently visited pages are cached in the location as specified in the settings.

NOTE: Both downloads and cache on /dev/shm worked fine in the current firefox on ubuntu 20.04.4. They had been set via settings and about:config. This problem is on ubuntu 22.04, which replaced the 20.04.

Comment 1

[:Gijs (he/him)]

(In reply to David Kra from comment #0)

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

Steps to reproduce:

Three settings ignored: Download directory, ask where to download, and cache directory.

Download Directory and ask where:

Using the about:preferences UI:
Change the download destination to /dev/shm or to /run/shm.
Uncheck "Always ask you where to save files".
Close the preferences page
Open another page. Hit <ctrl>s to save it.
Notice that the save-to dialog opens up. That should not happen.

Yes, it should. You're saving a file (rather than downloading) and that always prompts for a location. The equivalent item in the File menu has an ellipsis for this reason. If you're downloading a file (e.g. by clicking a link with a download attribute, or one that leads to a page where the webserver returns a content-type header the browser can't parse), this pref should take effect and there should be no "save as" dialog.

Notice where it defaults to as the destination does not match the preference.

If you were actually downloading something, I believe there would be no filepicker and the directory would be correct. If you're using a 'snap' or 'flatpak' build on Linux, it might not, for permissions/sandboxing reasons. It sounds like that might be what's happening here (see below).

It's a little hard to tell from your steps what page you're saving/downloading and if this is a clean profile. On a clean profile, I would expect this to match.

On a profile that's been in use for longer, "save file as" will have the filepicker default to the last directory where you saved files from that domain. The global stored setting for that is in the browser.download.lastDir pref you quoted, the per-site stored setting is in a different database.

[snip]

NOTE: Both downloads and cache on /dev/shm worked fine in the current firefox on ubuntu 20.04.4. They had been set via settings and about:config. This problem is on ubuntu 22.04, which replaced the 20.04.

This very much sounds like an issue with snap, then. bug 1769958 sounds fairly similar but was resolved wfm. Alexandre, can you help here? It's not clear to me from that ticket how users are supposed to fix an issue like this. See also the cache issue (snipped in my comment) - that's unrelated to downloads, so it seems to point to a snap issue rather than a change we made...

Comment 2

[:gerard-majax]

Changing download folder in settings to /dev/shm properly triggers portal, but then indeed any download fails, that's likely why you get prompted.

XDP: Handling SaveFile
XDP: Handling OpenFile
XDP: convert uri file:///dev/shm -> file:///run/user/1000/doc/219e3c49/shm

Comment 3

[:gerard-majax]

$ GD_DEBUG=1 /usr/libexec/xdg-document-portal -rv
[...]
XDP: LOOKUP 4:219e3c49
XDP: LOOKUP 4:219e3c49 => 7
XDP: LOOKUP 7:shm
XDP: LOOKUP 7:shm => b889b93fee107fb5
XDP: LOOKUP b889b93fee107fb5:firefox-104.0a1.fr.linux-x86_64.tar.bz2
XDP: LOOKUP -> error ENOENT
XDP: CREATE b889b93fee107fb5 firefox-104.0a1.fr.linux-x86_64.tar.bz2 WRONLY,APPEND,CREAT, 0100600
XDP: CREATE -> error EACCES
XDP: LOOKUP 7:shm
XDP: LOOKUP 7:shm => b889b93fee107fb5
XDP: LOOKUP b889b93fee107fb5:rv_CRM1Z.tar.part
XDP: LOOKUP -> error ENOENT
XDP: LOOKUP 7:shm
XDP: LOOKUP 7:shm => b889b93fee107fb5
XDP: LOOKUP b889b93fee107fb5:rv_CRM1Z.tar.part
XDP: LOOKUP -> error ENOENT
XDP: LOOKUP 7:shm
XDP: LOOKUP 7:shm => b889b93fee107fb5
XDP: LOOKUP b889b93fee107fb5:firefox-104.0a1.fr.linux-x86_64.tar.bz2
XDP: LOOKUP -> error ENOENT
XDP: LOOKUP 7:shm
XDP: LOOKUP 7:shm => b889b93fee107fb5
XDP: LOOKUP b889b93fee107fb5:firefox-104.0a1.fr.linux-x86_64.tar.bz2
XDP: LOOKUP -> error ENOENT
XDP: FORGET_MULTI 2
XDP: FORGET b889b93fee107fb5 5
XDP: FORGET 7 1

So we get denied by XDG Document portal: EACCES.

Comment 4

[:gerard-majax]

XDP: LOOKUP 5:shm => b889b93fee107fb5
XDP: LOOKUP b889b93fee107fb5:RQS-jKGL.tar.part
XDP: xdp_document_domain_can_write: entry=0x7ffb60005380
XDP: xdp_document_domain_can_write: entry=0x7ffb60005380 entry==NULL || !app_can_write_doc()
XDP: LOOKUP -> error ENOENT
XDP: CREATE b889b93fee107fb5 RQS-jKGL.tar.part WRONLY,CREAT,EXCL, 0100600
XDP: xdp_document_domain_can_write: entry=0x561431603360
XDP: xdp_document_domain_can_write: entry=0x561431603360 entry==NULL || !app_can_write_doc()
XDP: xdp_document_inode_checks: CREATE !can_write
XDP: CREATE -> error EACCES

So looks like we get denied by !app_can_write_doc()

Comment 5

[David Kra]

Problem solved!!
Problem source: Using firefox from the snap.
Solution: Download firefox from mozilla, Follow installation instructions. Customize configuration settings as desired.
Thank you for the efforts.
David - Breaking things and discovering what's already broken since 1954.

Comment 6

[:gerard-majax]

(In reply to David Kra from comment #5)

Problem solved!!
Problem source: Using firefox from the snap.
Solution: Download firefox from mozilla, Follow installation instructions. Customize configuration settings as desired.
Thank you for the efforts.
David - Breaking things and discovering what's already broken since 1954.

Well that's a workaround, i'm still asserting whether there is a bug on our side or in XDG Document Portal

Comment 7

[:gerard-majax]

Checking perms, we have current_perms = 5 (READ and GRANT_PERMISSIONS) and perms = 2 (WRITE) so obviously it refuses. I am not sure if it is expected.

Comment 8

[:gerard-majax]

Very much sounds like an upstream issue

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:gerard-majax, could you have a look please?

For more information, please visit auto_nag documentation.