[Bug 19873] New: Automated installation of gecko requires DOS path to root filesystem
http://bugs.winehq.org/show_bug.cgi?id=19873 Summary: Automated installation of gecko requires DOS path to root filesystem Product: Wine Version: 1.1.28 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: michael(a)araneidae.co.uk Running wine (after an upgrade) produces the message: err:mshtml:install_from_unix_file Could not get dos file name of "/usr/bin/../lib/../share/wine/gecko/wine_gecko-1.0.0-x86.cab" Could not load wine-gecko. HTML rendering will be disabled. I normally delete the Z: path (which points to /) from my wine configuration in an attempt to weakly jail the windows applications; from the error message the internal upgrade of wine_gecko appears to require this path to be present. This seems to be a bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Juan Lang <juan_lang(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #1 from Juan Lang <juan_lang(a)yahoo.com> 2009-08-28 14:32:25 --- That's because you've got wine_gecko installed in /usr/share/wine/gecko. You can avoid that by setting the GeckoUrl registry value, see http://wiki.winehq.org/UsefulRegistryKeys -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Michael Abbott <michael(a)araneidae.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | --- Comment #2 from Michael Abbott <michael(a)araneidae.co.uk> 2009-08-28 16:38:38 --- (In reply to comment #1)
That's because you've got wine_gecko installed in /usr/share/wine/gecko. You can avoid that by setting the GeckoUrl registry value
Sorry. Just because there is a registry workaround doesn't mean this bug is invalid. Actually, I don't understand what you're saying here. I have a working installation of wine that I have not tweaked, but it cannot find wine_gecko, even though it's looking in the right place(!) All I've done is install wine from the Ubuntu .deb packages provided on this very web site. Reverting your INVALID mark. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #3 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-08-28 19:02:10 --- Wine will attempt to download Wine_gecko over the network, if it's not found locally. There is nothing to fix here, it's the intended behavior. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #4 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-08-28 19:06:43 --- Closing. Lots of Wine parts relay on being able to access (/) regardless via what drive - z: or anything else. If you removing z: mapping, you creating unsupported configuration. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #5 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-08-28 19:42:42 --- (In reply to comment #2)
I have a working installation of wine that I have not tweaked, but it cannot find wine_gecko, even though it's looking in the right place(!) Wine_gecko was updated to 1.0.0. All new versions of Wine are now looking for it, not the 0.9.1. I think this is your problem.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Michael Abbott <michael(a)araneidae.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID | --- Comment #6 from Michael Abbott <michael(a)araneidae.co.uk> 2009-08-29 01:52:49 --- I'm going to reopen this one last time. (In reply to comment #3)
Wine will attempt to download Wine_gecko over the network, if it's not found locally.
There is nothing to fix here, it's the intended behavior.
And if it *is* found locally? (In reply to comment #4)
Closing. Lots of Wine parts relay on being able to access (/) regardless via what drive - z: or anything else. If you removing z: mapping, you creating unsupported configuration.
Well now. Maybe that's a separate bug to be raised separately, but that doesn't seem very sensible to me. For example, I have encountered windows apps which insist on scanning the entire visible file system: I don't *want* my entire file system visible to such programs! If you like, I'll open a separate bug report for this. (In reply to comment #5)
Wine_gecko was updated to 1.0.0. All new versions of Wine are now looking for it, not the 0.9.1. I think this is your problem.
Maybe I wasn't clear enough in my original report. The file /usr/bin/../lib/../share/wine/gecko/wine_gecko-1.0.0-x86.cab is present and exists; in other words, I have wine_gecko version 1.0.0 installed on my system, in the proper and official place: .deb 1.0.0-0ubuntu1 is installed, from the winehq repository. Reopening, because I don't think you're reading this report properly. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX --- Comment #7 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-08-29 12:19:54 --- Closing WONTFIX if you prefer. No, Wine can not access what's not mapped. Even if that file is found, Wine can't map UNIX path into windows path if there is no drive pointing there. You not just limiting windows programs but Wine itself as well. This is intended behavior - nothing to fix. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-08-29 12:23:23 --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4 Status|CLOSED |UNCONFIRMED CC| |jacek(a)codeweavers.com Resolution|WONTFIX | Severity|normal |minor --- Comment #9 from Jacek Caban <jacek(a)codeweavers.com> 2009-08-29 12:48:20 --- Well, not really. We could handle this case by coping this file to temp, symlinking or using an API that doesn't require DOS path. The installer is part of mshtml.dll so we can use UNIX API from there. Technically, if we require the package to be in a place that might be not accessible, then we should handle it properly. Anyway the downloading (although it's a deprecated method of installing Wine Gecko) should start automatically if installation from file fails. If it doesn't, that's another bug. Reopening and lowering priority. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #10 from Austin English <austinenglish(a)gmail.com> 2009-08-29 13:45:37 --- Confirming. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #11 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-08-29 23:36:55 --- ~/gecko does replace /usr/share/wine/gecko for those who prefer breaking their Wine installation by removing z: mapping. If they know how to remove z: they should know about ~/gecko. Playing games with temp won't help for other things depending on access to root file system like fonts available through font config. WONTFIX IMHO. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> 2009-08-30 02:39:42 --- There's no reason not to fix this, it isn't hard. Look at how we handle /usr/share/wine/wine.inf. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #13 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-08-30 22:04:05 --- (In reply to comment #12)
There's no reason not to fix this, it isn't hard. Look at how we handle /usr/share/wine/wine.inf.
That's for Wine internal handling, Windows applications expect a DOS path. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #14 from Jacek Caban <jacek(a)codeweavers.com> 2009-08-31 05:23:38 --- Wine Gecko package is also an internal thing. Note that it's just a cab file that we extract. The extracted installation needs to have a DOS patch, but it's already guaranteed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #15 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-08-31 07:17:20 --- The point was that removing the z: drive mapping leads to other breakages besides this bug. Making Gecko installation not require DOS path won't help with other things. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #16 from Michael Abbott <michael(a)araneidae.co.uk> 2009-09-03 13:04:11 --- (In reply to comment #15)
The point was that removing the z: drive mapping leads to other breakages besides this bug. Making Gecko installation not require DOS path won't help with other things.
What other breakages? It seems to me sensible to consider making it possible for Wine to work correctly *without* a link from Windows to the rest of the system. As it stands, wine provides a kind of jail which it can be fairly hard for applications to break out of; certainly pure Windows applications which are ignorant of Wine are likely to be jailed. Compelling the use of Z: pointing to the root of the system completely breaks this jailing, and makes it possible for Windows applications to, perhaps quite innocently, cause all sorts of problems. The most obvious example of this is the one I cited: a Windows application which for whatever reason decided to scan the ENTIRE file space -- I noticed because it took such a long time (and caused annoying problems with troublesome nfs mounts), and from that point I've *always* deleted Z: immediately after creating a fresh WINEPREFIX. This issue with the broken gecko update is the only problem I've ever noticed from deleting Z:, so I think there's no reason not to fix the gecko installer's pointless dependency on a Windows concept. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #17 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-03 22:53:07 --- Wine is not a jail or a virtualization environment of any kind. Wine does not make any efforts to limit Windows application's access. See the FAQ. Moreover Wine automatically adds drive mappings for new connected devices, making them accessible for Windows applications. You have to use native OS facilities to limit access to places that you don't want the apps can reach. Regarding other breakages do grep for z: in the registry. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #18 from Michael Abbott <michael(a)araneidae.co.uk> 2009-09-04 02:03:44 --- (In reply to comment #17)
Regarding other breakages do grep for z: in the registry.
$ grep -i z: ~/.wine/*.reg $ Nothing found. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #19 from Michael Abbott <michael(a)araneidae.co.uk> 2009-09-04 06:43:32 --- (In reply to comment #4)
Lots of Wine parts relay on being able to access (/) regardless via what drive - z: or anything else. If you removing z: mapping, you creating unsupported configuration.
http://wiki.winehq.org/FAQ section 10.1.5:
Consider removing the default Wine Z: drive, which maps to the unix root directory. This is only a weak defense, but it might help against some attacks.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #20 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-04 07:08:01 --- (In reply to comment #19)
http://wiki.winehq.org/FAQ section 10.1.5:
Consider removing the default Wine Z: drive, which maps to the unix root directory. This is only a weak defense, but it might help against some attacks.
You forgot the full context: "... The downside to this is you won't be able to run Windows applications that aren't reachable from a Wine drive (like C: or D:), so you might have to move downloaded installers to ~/.wine/drive_c before you can run them." Which is exactly the case of this bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #21 from Michael Abbott <michael(a)araneidae.co.uk> 2009-09-04 08:49:15 --- (In reply to comment #20)
(In reply to comment #19)
http://wiki.winehq.org/FAQ section 10.1.5:
Consider removing the default Wine Z: drive, which maps to the unix root directory. This is only a weak defense, but it might help against some attacks.
You forgot the full context:
"... The downside to this is you won't be able to run Windows applications that aren't reachable from a Wine drive (like C: or D:), so you might have to move downloaded installers to ~/.wine/drive_c before you can run them."
Which is exactly the case of this bug.
Since when was the gecko installer a Windows application? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #22 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-04 10:51:38 --- (In reply to comment #21)
Since when was the gecko installer a Windows application?
It's been that way since its introduction: http://wiki.winehq.org/BuildingWineGecko -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 --- Comment #23 from Austin English <austinenglish(a)gmail.com> 2009-09-04 13:22:00 --- (In reply to comment #20)
(In reply to comment #19)
http://wiki.winehq.org/FAQ section 10.1.5:
Consider removing the default Wine Z: drive, which maps to the unix root directory. This is only a weak defense, but it might help against some attacks.
You forgot the full context:
"... The downside to this is you won't be able to run Windows applications that aren't reachable from a Wine drive (like C: or D:), so you might have to move downloaded installers to ~/.wine/drive_c before you can run them."
Which is exactly the case of this bug.
As AJ and Jacek pointed out, for Gecko this is fixable. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 William J May <may.11b(a)runbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |may.11b(a)runbox.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Sylvain Petreolle <spetreolle(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle(a)yahoo.fr Platform|x86 |x86-64 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #24 from Jacek Caban <jacek(a)codeweavers.com> 2010-12-26 17:37:15 CST --- This bug seems to be fixed for a while now. wine_get_dos_file_name returns "\\?\unix\..." file name in this case and cabinet.dll works fine with it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19873 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #25 from Alexandre Julliard <julliard(a)winehq.org> 2011-01-07 12:39:49 CST --- Closing bugs fixed in 1.3.11. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org