-
Notifications
You must be signed in to change notification settings - Fork 557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google Earth Pro not working on Archlinux #3906
Comments
What does |
|
Where is GoogleEarthPro installed? In /usr/bin or somewhere in /opt? |
|
It seems to load |
|
this somehow sounds like |
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. |
For |
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. |
firejail/etc/inc/disable-programs.inc Lines 472 to 475 in fded293
It would be more secure to |
@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... |
@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! |
I'm reopening this so the OP can communicate on how to fix the issue. @rusty-snake Thanks for the speedy review! |
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. |
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).
|
@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... |
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. |
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! |
FTR #3978 (comment):
|
Firejail 0.9.64 version running Google Earth Pro 7.3.3.7786-4 installed from AUR repository:
And this is my local profile to make the program work:
The text was updated successfully, but these errors were encountered: