[Bug 56454] New: TclKit-based installer gets denied any write into any directory when launched via binfmt_misc
https://bugs.winehq.org/show_bug.cgi?id=56454 Bug ID: 56454 Summary: TclKit-based installer gets denied any write into any directory when launched via binfmt_misc Product: Wine Version: 9.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: sldev(a)free.fr Distribution: --- Created attachment 76213 --> https://bugs.winehq.org/attachment.cgi?id=76213 Reversal patch for admin privileges on process launch Greetings, I am the developer of a Second Life third party viewer (the Cool VL Viewer: http://sldev.free.fr/ ), and while the said viewer is developed under Linux and therefore got Linux native builds, I still use Wine to test its Windows builds (those builds are done in a VirtualBox VM that cannot run them). With Wine 9.4 I am facing a weird issue, where the installer (the super-old but totally gorgeous InstallJammer: https://sourceforge.net/projects/installjammer/ ), gets denied writing into *any* directory to install the program. However, this only occurs when the installer is launched via the binfmt_misc mechanism (i.e. the installer got the proper privileges when launched via the command line with 'wine <installer_executable>'). Looking at the diff between Wine 9.3 and 9.4, I could narrow down the issue to the new way programs are launched (via CreateProcessAsUserW() instead of CreateProcessW()) and came up with a reversal patch (attached) that does fix the issue. To reproduce the issue, download the latest Windows installer (there are weekly releases, so get the current one from: http://sldev.free.fr/index.php?page=download ), configure binfmt_misc for Wine on your Linux system (*), and launch the installer from your preferred file manager by clicking on its file. You will see that as soon as you start the installation (just after you chose the installation directory), the installer complains it does have permission to access the destination folder. (*) binfmt_misc configuration on my system: echo ':windows:M::MZ::/usr/bin/wine:' >/proc/sys/fs/binfmt_misc/register echo ':windowsPE:M::PE::/usr/bin/wine:' >/proc/sys/fs/binfmt_misc/register -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #1 from sldev <sldev(a)free.fr> --- Typo in my description: The last phrase must be read as "the installer complains it does *not* have permission to access the destination folder", of course... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |e92ba2de43d7afbe0704b11b29f | |7c30f44dfaeca Keywords| |regression CC| |z.figura12(a)gmail.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #2 from Zeb Figura <z.figura12(a)gmail.com> --- I can't seem to reproduce this? Although I also can't seem to get binfmt to trigger from dolphin, but even if I run the executable directly from the terminal using its path it still installs fine. I have zero idea why binfmt would even affect this, unless it's picking up wine from the wrong path somehow. Is it possible for you to get a log from the failing case? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #3 from sldev <sldev(a)free.fr> ---
I can't seem to reproduce this? Although I also can't seem to get binfmt to trigger from dolphin.
You do need to start it via binfmt_misc, or the bug won't trigger... Try another file manager ?
if I run the executable directly from the terminal using its path it still installs fine.
Yes, this is also what I did report...
Is it possible for you to get a log from the failing case?
Sure, but how do I get such a log ? When started with binfmt_misc (i.e. for the failing case), there is nothing printed anywhere. This said, I am not a Wine guru, so maybe there is another way ?
I have zero idea why binfmt_misc would even affect this, unless it's picking up wine from the wrong path somehow.
FYI, I also tried various binfmt_misc flags, (P, C, F), including the one dealing with the executable path, to no avail. Wild guess: maybe the fact the installer is a TlcKit one (i.e. a Tcl/Tk interpreter executing a Tcl/Tk program) is the reason; the privileges would not be propagated properly when started with binfmt_misc ?.... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #4 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to sldev from comment #3)
I can't seem to reproduce this? Although I also can't seem to get binfmt to trigger from dolphin.
You do need to start it via binfmt_misc, or the bug won't trigger... Try another file manager ?
if I run the executable directly from the terminal using its path it still installs fine.
Yes, this is also what I did report...
I mean without using "wine" though. I.e. just running whatsit(a)camazotz:~/Downloads$ ./CoolVLViewer-1.32.0.15-Windows-x86_64-Setup.exe succeeds. As I understand that should be going through binfmt_misc.
Is it possible for you to get a log from the failing case?
Sure, but how do I get such a log ?
When started with binfmt_misc (i.e. for the failing case), there is nothing printed anywhere. This said, I am not a Wine guru, so maybe there is another way ?
That sounds like "no" then unfortunately.
I have zero idea why binfmt_misc would even affect this, unless it's picking up wine from the wrong path somehow.
FYI, I also tried various binfmt_misc flags, (P, C, F), including the one dealing with the executable path, to no avail.
Wild guess: maybe the fact the installer is a TlcKit one (i.e. a Tcl/Tk interpreter executing a Tcl/Tk program) is the reason; the privileges would not be propagated properly when started with binfmt_misc ?....
I don't think so. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #5 from sldev <sldev(a)free.fr> --- (In reply to Zeb Figura from comment #4)
I mean without using "wine" though. I.e. just running
whatsit(a)camazotz:~/Downloads$ ./CoolVLViewer-1.32.0.15-Windows-x86_64-Setup.exe
succeeds. As I understand that should be going through binfmt_misc.
Well, yes, it would go via binfmt_misc to and for me it also fails this way...
That sounds like "no" then unfortunately.
Making it chmod +x and Running it directly from the terminal like you did lead to this log: 0088:fixme:wineusb:add_usb_device Interface 1 has 9 alternate settings; using the first one. 0088:fixme:wineusb:add_usb_device Interface 2 has 9 alternate settings; using the first one. 0088:fixme:wineusb:add_usb_device Interface 3 has 9 alternate settings; using the first one. 0088:fixme:wineusb:add_usb_device Interface 4 has 13 alternate settings; using the first one. 0088:fixme:wineusb:add_usb_device Interface 5 has 22 alternate settings; using the first one. 0088:fixme:wineusb:add_usb_device Interface 6 has 12 alternate settings; using the first one. 0084:fixme:wineusb:query_id Unhandled ID query type 0x5. .../... 31 more occurrences of the above mesage 0084:fixme:wineusb:query_id Unhandled ID query type 0x5. 0024:fixme:font:find_matching_face Untranslated charset 255 But all these message are emitted on installer launch, and before I try and install the program, at which point I just get the dialog reporting the permission problem from the installer, but no message printed by Wine in the terminal. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #6 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to sldev from comment #5)
(In reply to Zeb Figura from comment #4)
I mean without using "wine" though. I.e. just running
whatsit(a)camazotz:~/Downloads$ ./CoolVLViewer-1.32.0.15-Windows-x86_64-Setup.exe
succeeds. As I understand that should be going through binfmt_misc.
Well, yes, it would go via binfmt_misc to and for me it also fails this way...
Ah good, that should at least let us get logs then. Could you please attach a log when running that way with WINEDEBUG=+pid,+module ? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #7 from sldev <sldev(a)free.fr> --- Created attachment 76219 --> https://bugs.winehq.org/attachment.cgi?id=76219 Verbose log I expanded logging with 'export WINEDEBUG=warn+all' and re-ran the installer (*): I attached the log I got as debug.log.gz. Note that I could verify that all the temporary files listed in the log actually do exist, unlike what Wine is reporting... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #8 from Zeb Figura <z.figura12(a)gmail.com> --- Are you running Wine as root somehow? That's not supported.
002c:warn:virtual:virtual_map_builtin_module L"\\??\\C:\\windows\\system32\\ntdll.dll" found in WINEDLLPATH but not a builtin, ignoring
This is also weird; how did you install Wine?
I expanded logging with 'export WINEDEBUG=warn+all' and re-ran the installer (*):
This isn't a strict superset, because +module by itself enables the "trace" level, not just "warn". That said, on reflection I'm not sure that +module would have been interesting enough by itself. WINEDEBUG=+module,+file,+server,+pid,+process,+msi may be more revealing. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #9 from sldev <sldev(a)free.fr> --- Created attachment 76227 --> https://bugs.winehq.org/attachment.cgi?id=76227 New debug log
That said, on reflection I'm not sure that +module would have been interesting enough by itself. WINEDEBUG=+module,+file,+server,+pid,+process,+msi may be more revealing.
Here you go (debug2.log.gz). :-) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #10 from sldev <sldev(a)free.fr> ---
Are you running Wine as root somehow? That's not supported.
Yes, I am running Wine as root (and never had a single issue doing so), but also verified that I indeed got the exact same results as a normal user. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #11 from Zeb Figura <z.figura12(a)gmail.com> --- Sorry, I am still struggling to figure out what's even failing. There's no sign of any file access failing in the logs. Can you try adding +security,+relay please? Also, I assume you'd have said this, but do you have any custom Wine patches applied anywhere? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #12 from Zeb Figura <z.figura12(a)gmail.com> --- Actually, I looked again, and this looks like a duplicate of bug 56433, although I still have no idea why binfmt makes a difference. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #13 from sldev <sldev(a)free.fr> --- Created attachment 76232 --> https://bugs.winehq.org/attachment.cgi?id=76232 WINEDEBUG="+module,+file,+server,+pid,+process,+msi,+security,+relay" (In reply to Zeb Figura from comment #12)
Actually, I looked again, and this looks like a duplicate of bug 56433, although I still have no idea why binfmt makes a difference.
Perhaps, but when I use a (vanilla, no other patch) Wine v9.4 recompiled with (1) applied, anything launched via Wine refuses to start at all (and no message in the terminal when launched from it), not even wincfg, and I must kill "wine" manually... And before you ask, yes, I did the test with a non-root user as well. :-P (1) https://source.winehq.org/git/wine.git/blobdiff_plain/929732034c383e94e814d7...
Can you try adding +security,+relay please?
Here you go (debug3.log.gz) :-) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #14 from sldev <sldev(a)free.fr> --- Created attachment 76233 --> https://bugs.winehq.org/attachment.cgi?id=76233 #2 WINEDEBUG="+module,+file,+server,+pid,+process,+msi,+security,+relay" Sorry, forgot to 'export' WINEDEBUG... Proper log attached. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #15 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to sldev from comment #13)
Created attachment 76232 [details] WINEDEBUG="+module,+file,+server,+pid,+process,+msi,+security,+relay"
(In reply to Zeb Figura from comment #12)
Actually, I looked again, and this looks like a duplicate of bug 56433, although I still have no idea why binfmt makes a difference.
Perhaps, but when I use a (vanilla, no other patch) Wine v9.4 recompiled with (1) applied, anything launched via Wine refuses to start at all (and no message in the terminal when launched from it), not even wincfg, and I must kill "wine" manually...
That's odd. Does a manual build without that patch work? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #16 from sldev <sldev(a)free.fr> --- (In reply to Zeb Figura from comment #15)
That's odd. Does a manual build without that patch work?
Nope... O.O In fact, I cannot rebuild a working version of Wine on this computer any more, while all the versions I compiled on it before the 16th of March still work ! I reverted every package update I did after this date, to no avail. This is incredible, and something I never saw happening so far ! If you have any idea about what could cause wineboot to eat up 100% of a core and never finish when built on a computer and not another, I'm all ears... In any case, I rebuilt Wine 9.4 with the loader.c patch on another PC, and installed the resulting package on both that second PC and the "broken" PC, and it works like a charm, indeed also fixing the binfmt_misc permission bug for me ! Case closed. :-) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 --- Comment #17 from sldev <sldev(a)free.fr> --- Silly me !!! I found the cause of the build breakage... Today, to diagnose a linking issue in another program, I switched the 'ld' alternative to ld.lld (the clang linker, which emits more verbose error messages); apparently, the latter does not work for compiling Wine (strange, still), and reverting to ld.bfd allows to build working Wine versions again... Phew ! :-D -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #18 from Zeb Figura <z.figura12(a)gmail.com> --- Okay, I'm going to go ahead and mark this as a duplicate then. *** This bug has been marked as a duplicate of bug 56433 *** -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56454 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #19 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Closing duplicate -- 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)
-
WineHQ Bugzilla