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@winehq.org ReportedBy: michael@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #1 from Juan Lang juan_lang@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
http://bugs.winehq.org/show_bug.cgi?id=19873
Michael Abbott michael@araneidae.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID |
--- Comment #2 from Michael Abbott michael@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #3 from Vitaliy Margolen vitaliy@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Vitaliy Margolen vitaliy@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #5 from Vitaliy Margolen vitaliy@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
Michael Abbott michael@araneidae.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID |
--- Comment #6 from Michael Abbott michael@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX
--- Comment #7 from Vitaliy Margolen vitaliy@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Vitaliy Margolen vitaliy@kievinfo.com 2009-08-29 12:23:23 --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=19873
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4 Status|CLOSED |UNCONFIRMED CC| |jacek@codeweavers.com Resolution|WONTFIX | Severity|normal |minor
--- Comment #9 from Jacek Caban jacek@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #10 from Austin English austinenglish@gmail.com 2009-08-29 13:45:37 --- Confirming.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #11 from Dmitry Timoshkov dmitry@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #12 from Alexandre Julliard julliard@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #13 from Dmitry Timoshkov dmitry@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #14 from Jacek Caban jacek@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #15 from Dmitry Timoshkov dmitry@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #16 from Michael Abbott michael@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #17 from Dmitry Timoshkov dmitry@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #18 from Michael Abbott michael@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #19 from Michael Abbott michael@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #20 from Dmitry Timoshkov dmitry@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #21 from Michael Abbott michael@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?
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #22 from Dmitry Timoshkov dmitry@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
http://bugs.winehq.org/show_bug.cgi?id=19873
--- Comment #23 from Austin English austinenglish@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
William J May may.11b@runbox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |may.11b@runbox.com
http://bugs.winehq.org/show_bug.cgi?id=19873
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr Platform|x86 |x86-64
http://bugs.winehq.org/show_bug.cgi?id=19873
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #24 from Jacek Caban jacek@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.
http://bugs.winehq.org/show_bug.cgi?id=19873
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Alexandre Julliard julliard@winehq.org 2011-01-07 12:39:49 CST --- Closing bugs fixed in 1.3.11.
-
wine-bugs＠winehq.org