Open Bug 1467094 Opened 4 years ago Updated 1 year ago

Import from the Chromium Snap profile doesn't work

Categories

(Firefox :: Migration, defect, P2)

All
Linux
defect

Tracking

()

People

(Reporter: j.jakhaia, Unassigned)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180517114003

Steps to reproduce:

I've tried tried import bookmarks from Chromium browser on Ubuntu 18.04


Actual results:

Firefox can't detect Chromium browser


Expected results:

Chromium browser detection
Component: Untriaged → Migration
Hello, we are supposed to support Chromium imports on Linux but it's possible Ubuntu installs it in a different place.[1]

Can you open chrome://version/ while in Chromium and share the "Profile Path" directory?

[1] https://dxr.mozilla.org/mozilla-central/rev/cec4a3cecc29ff97860198969b6fdff24b9e93bb/browser/components/migration/ChromeMigrationUtils.jsm#221,238-239
Flags: needinfo?(j.jakhaia)
On Ubuntu 16.04 my profile path for Chromium is: /home/sfoster/.config/chromium/Default
Import of Chromium bookmarks into a new nightly profile worked for me. It would seem odd (though I guess possible) that the profile paths would change in 18.04?
Here is output

Chromium	67.0.3396.62 (Official Build) (64-bit)
Revision	babbbb5b433370f9a7feeb9f98a57599ad1c4676-refs/branch-heads/3396@{#702}
OS	Linux
JavaScript	V8 6.7.288.42
Flash	(Disabled)
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/67.0.3396.62 Chrome/67.0.3396.62 Safari/537.36
Command Line	/snap/chromium/353/usr/lib/chromium-browser/chromium-browser --no-default-browser-check --no-first-run --password-store=basic --ppapi-flash-path --flag-switches-begin --flag-switches-end
Executable Path	/snap/chromium/353/usr/lib/chromium-browser/chromium-browser
Profile Path	/home/ubuntu/snap/chromium/353/.config/chromium/Default

Ubuntu 18.04 now uses snappy for installation.
I have installed Chromium from Ubuntu Software app
Flags: needinfo?(j.jakhaia)
> Profile Path	/home/ubuntu/snap/chromium/353/.config/chromium/Default

Hmm… looks like the Snap uses a different profile path… I think https://git.launchpad.net/~chromium-team/chromium-browser/+git/snappy-packaging/tree/snap may be the code for the snap but I'm not sure since there are a few and I don't see $CHROME_USER_DATA_DIR or --user-data-dir= getting set there[1]

I'm wondering what the significance of "353" is in the profile path? I'm guessing we can't hard-code that in our search. We need to figure out how to find this profile path in a reliable way.

[1] https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Summary: Bookmark Import from Chromium → Import from the Chromium Snap profile doesn't work
(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #4)
> > Profile Path	/home/ubuntu/snap/chromium/353/.config/chromium/Default
> 
> …
> I'm wondering what the significance of "353" is in the profile path? I'm
> guessing we can't hard-code that in our search. We need to figure out how to
> find this profile path in a reliable way.

jlorenzo, any suggestions for how we could reliably find this directory from Firefox? I guess we would need to do the same for the other channels of chromium too if they use different paths.
Flags: needinfo?(jlorenzo)
That's a very good question! I'm not sure we can access the config of another snap. I didn't find the right permission to give. Moreover, we ship with the "strict" confinement[2], which restricts the access to the list given at [3].

Ken, Olivier, is there a way to add new whitelisted paths to the confinment, without setting the level to something lower than strict?

[1] https://docs.snapcraft.io/reference/interfaces
[2] https://searchfox.org/mozilla-central/rev/c621276fbdd9591f52009042d959b9e19b66d49f/taskcluster/docker/firefox-snap/snapcraft.yaml.in#5
[3] https://docs.snapcraft.io/reference/confinement
Component: Migration → Release Automation: Snap
Flags: needinfo?(olivier)
Flags: needinfo?(ken.vandine)
Flags: needinfo?(jlorenzo)
Product: Firefox → Release Engineering
QA Contact: jlorenzo
Version: 60 Branch → unspecified
(In reply to Johan Lorenzo [:jlorenzo] from comment #6)
> That's a very good question! I'm not sure we can access the config of
> another snap. I didn't find the right permission to give. Moreover, we ship
> with the "strict" confinement[2], which restricts the access to the list
> given at [3].
> 
> Ken, Olivier, is there a way to add new whitelisted paths to the confinment,
> without setting the level to something lower than strict?
> 
> [1] https://docs.snapcraft.io/reference/interfaces
> [2]
> https://searchfox.org/mozilla-central/rev/
> c621276fbdd9591f52009042d959b9e19b66d49f/taskcluster/docker/firefox-snap/
> snapcraft.yaml.in#5
> [3] https://docs.snapcraft.io/reference/confinement

I know importing from another browser is an existing feature, however we consider a snap knowing about other snaps that are installed an information leak.  This is a powerful feature of snap confinement.
Flags: needinfo?(ken.vandine)
I don't know much about Snaps but suppose a non-Snap Firefox build wants to import from a Chromium Snap, is that possible and how should we find the profile path?
OS: Unspecified → Linux
Hardware: Unspecified → All
A symlink to the current revision of the chromium snap's local data:

$HOME/snap/chromium/current
Flags: needinfo?(olivier)
Component: Release Automation: Snap → Migration
Product: Release Engineering → Firefox
QA Contact: jlorenzo
Duplicate of this bug: 1657370

(In reply to Ken VanDine from comment #9)

A symlink to the current revision of the chromium snap's local data:

$HOME/snap/chromium/current

It looks like on my machine this is actually under:

~/snap/chromium/common/chromium/

which makes sense, because it probably needs to stay accessible when the chromium version changes (ie after updates) - does that look right?

Flags: needinfo?(ken.vandine)

Yes, that's right. The location where the profile folder is stored for the chromium snap changed recently, it is now in ~/snap/chromium/common/chromium/.

(In reply to Olivier Tilloy from comment #12)

Yes, that's right. The location where the profile folder is stored for the chromium snap changed recently, it is now in ~/snap/chromium/common/chromium/.

Thanks for confirming!

(In reply to Ken VanDine from comment #7)

I know importing from another browser is an existing feature, however we
consider a snap knowing about other snaps that are installed an information
leak. This is a powerful feature of snap confinement.

On macOS (on Mojave 10.14 and later) Safari now does this but only for their own stuff (that is, other applications can't get to Safari's data by default anymore, but Safari can get to Firefox/Chrome/...'s). On macOS, we can holepunch the sandbox by showing a file picker and allowing the user to pick the file they want the application to access, so that we can still offer bookmark import with user consent.

Does snap confinement have any similar way of holepunching the sandbox with user consent?

Flags: needinfo?(olivier)
Duplicate of this bug: 1667144

:Gijs just to follow up from 1667144, what should happen when there's two profile folders - one in the old location and one in the new snap location.

(In reply to Sarah Bird from comment #15)

:Gijs just to follow up from 1667144, what should happen when there's two profile folders - one in the old location and one in the new snap location.

Yeeeeaaaah. It should probably use the most recently modified one. We can determine this if we can access the files, but not if we ourselves are in a snap package and can't read the snap files.

(In reply to :Gijs (back Dec 1; he/him) from comment #13)

Does snap confinement have any similar way of holepunching the sandbox with user consent?

Sorry for the very late reply. Not that I know of. That would really defeat the purpose of strict application confinement.

Flags: needinfo?(olivier)

(In reply to Olivier Tilloy from comment #17)

(In reply to :Gijs (back Dec 1; he/him) from comment #13)

Does snap confinement have any similar way of holepunching the sandbox with user consent?

Sorry for the very late reply.

No worries!

Not that I know of. That would really defeat the purpose of strict application confinement.

I'm confused. The toolkit (GTK or otherwise) filepicker can navigate to other files, that the snap package cannot otherwise access, right? And then the user can open those files with the snap application, right? (Or does snap completely break opening all files not in the snap package?) That doesn't "defeat the purpose of strict application confinement" - it allows users to pick a specific file that they want to give the file access to.

This is basically the same thing, from my perspective. We want a way for the user to say "yes, Firefox should have access to this file". Is that not possible? Or perhaps only via the toolkit filepicker, if the user manually navigates to the file in question?

Flags: needinfo?(olivier)

(In reply to :Gijs (he/him) from comment #18)

This is basically the same thing, from my perspective. We want a way for the user to say "yes, Firefox should have access to this file". Is that not possible? Or perhaps only via the toolkit filepicker, if the user manually navigates to the file in question?

That's right, filepickers work because an out-of-process XDG portal is used under the hood (where available). This requires user confirmation.
So if the profile importer uses a filepicker, that would theoretically work. Automatically detecting an existing profile and importing it without user intervention wouldn't work.

Flags: needinfo?(olivier)

Clearing NI since question was answered by Olivier.

Flags: needinfo?(ken.vandine)

Given that the only option is using a file picker, is this something we are willing to do? Or is this a WONTFIX.

It's simply not possible to autoimport things outside the Snap sandbox.

(In reply to Mike Kaply [:mkaply] from comment #21)

Given that the only option is using a file picker, is this something we are willing to do? Or is this a WONTFIX.

It's simply not possible to autoimport things outside the Snap sandbox.

I think the importer dialog should check whether it's in a Snap or other kind of sandbox and provide some appropriate message, and then use a file picker in response to user request, yes.

You need to log in before you can comment on or make changes to this bug.