mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5696] microsoft-edge-stable: cannot launch with default profile #3067
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3067
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @GreatBigWhiteWorld on GitHub (Feb 28, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5696
firejail version 0.9.70
Any hint?
Edit: It's strange that the default profile only had microsoft-edge while the app was called microsoft-edge-stable
So creating a profile under ~/.config/firejail/ for microsoft-edge-stable with the content of microsoft-edge profile fixed it.
@ghost commented on GitHub (Feb 28, 2023):
Should be unrelated to this, but still, try to upgrade to the latest stable release, which is 0.9.72 at the time of writing.
The issue seems to be caused by a missing profile for
microsoft-edge-stable, and Firejail falls back to itsdefault.profile(which isn't suited for a chromium-based web browser like edge). We do have microsoft-edge, microsoft-edge-beta and microsoft-edge-dev. If you could try placing the below in ~/.config/firejail/microsoft-edge-stable.profile and trying again, we can fix this:@ghost commented on GitHub (Feb 28, 2023):
Yeah, that's what I was thinking. Re-opened because we should fix this by adding such
microsoft-edge-stable.profile. Can you confirm you have a working sandbox when using the options frommicrosoft-edge.profileand not the ones like in my post above? In that case the stable channel might have renamed its binary only, and we can edit things accordingly.Thanks for opening this, it's valuable info!
@GreatBigWhiteWorld commented on GitHub (Feb 28, 2023):
Hi, thanks for the input.
Well, I just happened to run into another issue: the browser can't remember its last running session at all.
It always launches like I have just installed it: welcome screen, MS account sync login. Everything is lost after closing the browser.
I did recreate the microsoft-edge-stable.profile using the content in your previous post since it's more accurate than the microsoft-edge-dev.profile.
Any idea?
@ghost commented on GitHub (Feb 28, 2023):
Hmm, might have to do with the noblacklist, mkdir, whitelist routine. In my previous post I used
microsoft-edge-stablefor all 3. But perhaps this is incorrect and the stable channel still usesmicrosoft-edge. Can you try moving anything vital you have out of the way and start with a fresh profile? That should at least clear up which ~/.cache and ~/.configure subfolder it is using.I'm in the middle of downloading the stable, beta and dev channel versions on my machine to check as well. Will keep you updated on that here.
@ghost commented on GitHub (Feb 28, 2023):
UPDATE: Here's my test results. I can get a hardened, fully working sandbox for the stable channel version with the below (redirect) profile. I also noticed msedge uses its own name for the browser's internal sandbox and added that in too (so not chrome-sandbox what our current profiles assume). Latest running session and other configuration changes are respected, so I guess this will suffice.
Take all the time you need to test with these updated files. We can bring in the needed changes later. For now we should focus on getting your browsing restored to what you're used to, all included.
@kmk3 commented on GitHub (Feb 28, 2023):
@GreatBigWhiteWorld on Feb 28:
It could be that this version uses different names for its directories, such as
~/.config/microsoft-edge-stableinstead of~/.config/microsoft-edgeorvice-versa.
The directories that it creates can be checked by running it in a temporary
home with
--private.What is the output of the following?
@GreatBigWhiteWorld commented on GitHub (Feb 28, 2023):
@kmk3
@glitsj16
If I copy your disable-common.local and microsoft-edge-stable to .config/firejail. The issue (not remebering previous session) persists. In my noobie opinion, your redirect to microsoft-edge.profile doesn't make sense because it redirects to microsoft-edge-dev.profile again, which doesn't whitelist
So I added these whitelist in the .config/firejail/microsoft-edge-stable.profile, and I changed the redirect back to chromium-common.profile
What's the disable-common.profile do? It seems not included anywhere?
@ghost commented on GitHub (Feb 28, 2023):
That's very odd.
Nothingredirects tomicrosoft-edge-dev.profile. At least not for me. The relevant profiles all redirect tochromium-common.profile, as they should. Please double-check your setup.That's disable-common.inc, not disable-common.profile. It's a vital part of how Firejail works. All files referenced in there are blacklisted, meaning they won't be part of the resulting sandbox. A specific counterpart option (noblacklist foo) is included in a application-specific profile when something needs to be accessible inside the sandbox. Same goes for the other main disable-xxx.inc files.
@GreatBigWhiteWorld commented on GitHub (Feb 28, 2023):
Here's the content of the default microsoft-edge.profile on my machine:
It has nothing but redirects to dev.profile, which by default has the content:
@ghost commented on GitHub (Feb 28, 2023):
Wow, I didn't check the history of the msedge profiles. You're correct, 0.9.70 does have that unexpected include, as can be seen here. Upgrade your Firejail installation if you can, there might be other fixed bugs and important changes.
@kmk3 commented on GitHub (Apr 5, 2023):
From what I understand #5697 should have fixed some of these issues.
@GreatBigWhiteWorld
Can you build/install firejail from master and see if you can still reproduce
the issues?
Also, what distribution are you using?
@GreatBigWhiteWorld commented on GitHub (Apr 17, 2023):
Sorry but I'm no longer in an environment to test that. I guess it was due to an older version of firejail and would not be an issue in newer versions.