mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3906] google-earth-pro: program does not work on Arch Linux #2447
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#2447
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 @X6B on GitHub (Jan 21, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3906
Firejail 0.9.64 version running Google Earth Pro 7.3.3.7786-4 installed from AUR repository:
google-earth-pro
And this is my local profile to make the program work:
@rusty-snake commented on GitHub (Jan 21, 2021):
What does
firejail --ignore=private-bin --profile=google-earth ls -l /usr/bin/google-earthshow?@X6B commented on GitHub (Jan 21, 2021):
@reinerh commented on GitHub (Jan 22, 2021):
Where is GoogleEarthPro installed? In /usr/bin or somewhere in /opt?
@X6B commented on GitHub (Jan 22, 2021):
/opt/google/earth/pro/@reinerh commented on GitHub (Jan 23, 2021):
Reading profile /etc/firejail/google-earth.profileIt seems to load
google-earth.profileinstead ofgoogle-earth-pro.profile.Can you try using this one?
firejail --profile=/etc/firejail/google-earth-pro.profile google-earth-pro(It shouldn't be necessary to speficy the profile, but for some reason it didn't load the pro profile in your first post)
@X6B commented on GitHub (Jan 23, 2021):
@reinerh commented on GitHub (Jan 23, 2021):
this somehow sounds like
/usr/local/bin/google-earth-prois a shell script.you probably have to add all binaries called by the script (like
readlink) to private-bin.or maybe it's easer to remove private-bin from your google-earth-pro.profile and google-earth.profile.
@ghost commented on GitHub (Jan 23, 2021):
I've just installed the google-earth-pro package from AUR to help debug this. I must say there's quite a few things going awkward with the app, even without any sandboxing. Need some time to investigate thoroughly but at least I see the package installs a shell script in /usr/bin/google-earth-pro so I'm wondering how/what ended up in /usr/local/bin exactly.
@X6B can you post you local override here (giving us its full name as well) so we can follow the complete train of events.
UPDATE: Our current google-earth-pro.profile doesn't support including a google-earth-pro.local (something we need to fix). I suspect that's why both private-bin readlink and private-bin google-earth-pro are not actually called and the app fails to start. For now a google-earth.local should be used instead.
@rusty-snake commented on GitHub (Jan 23, 2021):
For
private-bin readlink,dirname,basename,grep,sed,...it will work, but forignore private-binnot.@ghost commented on GitHub (Jan 23, 2021):
Correct, just tripped over that one.
I'm not understanding why we blacklist/mkdir/mkfile these paths under ${HOME}/.googleearth. They make the firejailed app throwing error windows with the message: Could not save "My Places". A copy can be found in "/home/glitsj16/.googleearth/myplaces.kml.tmp". For me everything starts to fall into place when blacklisting/mkdir/whitelisting ${HOME}/.googleearth itself instead. That implies changing disable-programs.inc as well obviously and I could understand that for a less experienced user that just installed google-earth-pro and wants to firejail it things get really complicated. Hence I'm marking this as a bug.
@rusty-snake commented on GitHub (Jan 23, 2021):
fded293479/etc/inc/disable-programs.inc (L472-L475)It would be more secure to
blacklist ${HOME}/.googleearth. If for example a new G-Earth version starts to execute plug-ins located in e.g.~/.googleearth/pluginsthis could be used to escape the sandbox. (admittedly rather theoretical)@ghost commented on GitHub (Jan 23, 2021):
@rusty-snake I fully agree and did so in the PR. At least on my system google-earth-pro already added ${HOME}/.googleearth/My Style Templates...
@ghost commented on GitHub (Jan 23, 2021):
@X6B As you see we're on top of this. Please hang on while the needed changes trickle down and the related PR gets merged. I'm pretty sure we can fix this properly. Thanks for bringing this to our attention!
@ghost commented on GitHub (Jan 23, 2021):
I'm reopening this so the OP can communicate on how to fix the issue.
@rusty-snake Thanks for the speedy review!
@X6B commented on GitHub (Jan 24, 2021):
I tried your git changes and the program starts and works fine after deleting my old .googlearth folder, but i can´t reopen it because of this:
If i delete the ".instant-running-lock" folder inside .googleearth, the program crashes when i open it again.
For now google-earth-pro only works fine the first time, when there is not any .googleearth folder at home.
@X6B commented on GitHub (Jan 24, 2021):
That /usr/local/bin/google-earth-pro was created by firecfg!
As i said in my first message, adding readlink and google-earth-pro to private-bin on my google-earth-pro local profile fixed the issue (before the git changes).
@ghost commented on GitHub (Jan 25, 2021):
@X6B Confirming I see this too.
Oddly enough, for me (also running Arch Linux btw) this doesn't happen after rm -f ${HOME}/.googleearth/instance-running-lock before starting it again. When that folder is removed it starts happily again here. A basic shell wrapper script can handle this, but I agree that's an ugly workaround at best (not to mention things breaks for users using firecfg). Without firejail I noticed GEP doesn't properly remove that path (which is a symlink to /proc/) after shutting down, resulting in a dangling symlink. That should be fixed upstream IMO. As firejail uses a special setup for /proc this symlink always stays intact, confusing GEP into believing it is still running, so it throws that message shown by you above when you try to start it again. We would need a way to remove a file/dir on the real filesystem after shutting down the sandbox. That kind of functionality does not exist in firejail AFAIK.
I do realize this is not good news. The above - if correct - only hints at explaining what's going on. Playing with the profile hasn't resulted in a clean way to 'fix' this behaviour yet, if at all possible. Looks like an upstream bug that we can't do much about. It's my very first encounter with google-earth-pro though, so perhaps there's something I'm not seeing here.
On a related note there's much more to be done to the profile. Functionality like opening Google Maps, mail and a web browser for example is currently broken/missing in the firejail sandbox too. I'll keep playing with the app and the profiles, just wanted to inform you on where I'm at currently...
@X6B commented on GitHub (Jan 27, 2021):
As this is a pain in the ass, I'll use the web version instead: https://earth.google.com/web/
It's basically the same thing.
@ghost commented on GitHub (Jan 28, 2021):
I fully understand your sentiment. In a follow-up PR I'll add extensive comments on this sad situation. Upstream is hardly interested it seems, let alone easily contactable. I wonder if we should disable it in firecfg or drop it completely. That's ofcourse not a decision for me to take on my own. In any case, thanks for reporting it, at least we're in the know!
@rusty-snake commented on GitHub (Apr 6, 2021):
FTR https://github.com/netblue30/firejail/issues/3978#issuecomment-778130183: