September 2010 - Wine-Devel

Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace

by Alexandre Julliard

Scott Ritchie <scott(a)open-vote.org> writes: > Ubuntu 10.10 is coming out soon, and its new kernel settings prevent > Wine apps from looking at each others' memory. This breaks World of > Warcraft, among other things. See: > http://bugs.winehq.org/show_bug.cgi?id=24193 > > What's needed is a very small shim for Wine that can be setuid 0, but > then release all capabilities except what Wine actually needs -- what a > normal user has, and cap_sys_ptrace. I don't think that's a good idea. CAP_SYS_PTRACE allows access to any process, so it's a lot more dangerous than the standard ptrace checks that Ubuntu decided to break. Going back to the default behavior is probably safer than making Wine setuid... -- Alexandre Julliard julliard(a)winehq.org

Sept. 29, 2010

Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace

by Henri Verbeet

On 29 September 2010 15:42, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > On 09/29/2010 03:14 PM, Scott Ritchie wrote: >> >> Ubuntu 10.10 is coming out soon, and its new kernel settings prevent >> Wine apps from looking at each others' memory. This breaks World of >> Warcraft, among other things. See: >> http://bugs.winehq.org/show_bug.cgi?id=24193 >> >> What's needed is a very small shim for Wine that can be setuid 0, but >> then release all capabilities except what Wine actually needs -- what a >> normal user has, and cap_sys_ptrace. > > Pardon my ignorance but why is Ubuntu restricting the ptrace'ing of > processing belonging to the same uid? > See http://lkml.org/lkml/2010/6/29/401 for some background on this. I think the conclusion from that thread was essentially that ptrace restrictions and the like should be done using something like SELinux instead.

Sept. 29, 2010

Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite

by Henri Verbeet

On 29 September 2010 08:21, Travis Athougies <iammisc(a)gmail.com> wrote: >> The problem with your current setup is that you do the readback after >> doing a Present(). Present() invalidates the contents of the >> backbuffer. >> >>> + ok(data[0] == D3DCOLOR_ARGB(0, 0, 255, 255), >>> + "swizzle_test: Got color %08x (should be 0x0000FFFF)\n", data[0]); >> While I doubt you're going to care a lot for this specific test, I >> think it makes sense to integrate something like color_match() from >> the d3d9 tests right from the start. In fact, I think the way you want >> to do this is to keep the actual testing inside >> compile_pixel_shader9(). E.g., you could pass it an array with things >> like probe locations, expected values, allowed deviations and failure >> messages. > > I'm wondering... Inside compile_pixel_shader9? or compute_pixel_shader9? I'm > thinking that this might make the argument list of > compile_pixel_shader9 really really > ugly. I'm unsure of exactly what you're telling me here? Could you be > more explicit? > Sorry, in compute_pixel_shader9(). You'd do something like this: struct test_data { UINT x, y; D3DCOLOR color; UINT max_dev; const char *message; }; struct test_data test_data[] = { {320, 240, D3DCOLOR_ARGB(0x00, 0xff, 0xff, 0x00), 1, "Some failure message"}, ... }; Then pass the test data array to compute_pixel_shader9() which would loop through it and do the actual tests. You'd probably also want to pass __LINE__. Note that this specific structure would be a problem for floating point data though; you'll probably want to use floating point values for your expected data everywhere, and just convert D3DCOLOR result data to floating point inside compute_pixel_shader9().

Sept. 29, 2010

Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace

by Michael Stefaniuc

On 09/29/2010 03:14 PM, Scott Ritchie wrote: > Ubuntu 10.10 is coming out soon, and its new kernel settings prevent > Wine apps from looking at each others' memory. This breaks World of > Warcraft, among other things. See: > http://bugs.winehq.org/show_bug.cgi?id=24193 > > What's needed is a very small shim for Wine that can be setuid 0, but > then release all capabilities except what Wine actually needs -- what a > normal user has, and cap_sys_ptrace. Pardon my ignorance but why is Ubuntu restricting the ptrace'ing of processing belonging to the same uid? > On an Ubuntu system, this is very similar to what DHCP and PING do -- > setuid 0, however they drop all privs except cap_net_rawio at the start. > Existing code can be used: > http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/ann… > http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/ann… > > > Basically, I need someone to write this shim for me. The long term > solution is probably to just package Wine such that the wine binary > itself has cap_sys_ptrace, however currently Ubuntu has no support for > this kind of extended attribute in the packaging system so workarounds > like the above for DHCP need to be done. I suspect other distros have > similar issues. Doubt that Fedora has that problem as they are using SELinux to restrict what processes can do. There is a policy for Wine and rpm supports the setting of the correct SELinux context on rpm installation/upgrade time. bye michael

Sept. 29, 2010

Re: winex11: Add support for animated cursors in X11 driver (try 2).

by Erich Hoover

On Wed, Sep 29, 2010 at 6:29 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > I didn't really look at the patch at all, but that's not how > HeapReAlloc() works. > Whoops! I can't believe I screwed that up, thanks. Erich Hoover ehoover(a)mines.edu

Sept. 29, 2010

Re: mshtml and friends

by Jacek Caban

On 9/29/10 3:03 PM, Reece Dunn wrote: > On 29 September 2010 13:45, Jacek Caban<jacek(a)codeweavers.com> wrote: >> The >> problem is probably somewhere else and the question is why the script takes >> code path resulting in an exception (and even if it's supposed to do so, >> current exception handling is probably good enough for it). > The problem with the current wine tip is that > 'fixme:jscript:new_expression_eval throw TypeError' line. Since this > is triggered in the main script (not in a try ... catch block) it will > not get handled properly. Sure, but if you want to test new_expression_eval behavior, it's enough and better as the code is cleaner. OnScriptError is a separate problem. >>> a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function >> That's not the right place. See exception_test in api.js for exceptions >> test. It's obviously not testing OnScriptError, but most tests should go >> there. > This is what step (1) is testing: > > exception_test(function() {new null;}, "TypeError", ...); > > which is great if you have something like: > > <script>try { new null; } catch (e) { ... }</script> > > but not something like: > > <script>new null;</script> > > This triggers (http://msdn.microsoft.com/en-us/library/shbz8x82%28v=VS.85%29.aspx) > the IActiveScriptSite_OnScriptError callback notification. This is > what I intend on testing in the dlls/jscript/tests/activex.c tests as > I need to inspect that call when executing this type of > unhandled/uncaught exception, which is what will happen in the Big > Fish Games client. You have run.c for that. activex.c is, as the name suggests, for testing ActiveXObject-related stuff. Jacek

Sept. 29, 2010

Wanted: small C program to drop all capabilities but cap_sys_ptrace

by Scott Ritchie

Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. On an Ubuntu system, this is very similar to what DHCP and PING do -- setuid 0, however they drop all privs except cap_net_rawio at the start. Existing code can be used: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/ann… http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/ann… Basically, I need someone to write this shim for me. The long term solution is probably to just package Wine such that the wine binary itself has cap_sys_ptrace, however currently Ubuntu has no support for this kind of extended attribute in the packaging system so workarounds like the above for DHCP need to be done. I suspect other distros have similar issues. Thanks, Scott Ritchie

Sept. 29, 2010

Re: mshtml and friends

by Reece Dunn

On 29 September 2010 13:45, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 9/29/10 2:30 PM, Reece Dunn wrote: >> >> On 29 September 2010 11:39, Jacek Caban<jacek(a)codeweavers.com> wrote: >>> >>> On 9/28/10 9:37 PM, Reece Dunn wrote: >>>> >>>> On 28 September 2010 15:14, Jacek Caban<jacek(a)codeweavers.com> wrote: >>>>>> >>>>>> I am interested in helping out to improve this area -- my aim is to >>>>>> not require the `winetricks ie6` command to get some of these >>>>>> applications (specifically the Big Fish Games client) to a usable >>>>>> state. >>>>>> >>>>>> Therefore, I am wondering if anyone knows where the best place is to >>>>>> start looking (e.g. known areas of missing functionality) or how to >>>>>> debug applications (and interpret WINEDEBUG output) to identify where >>>>>> the issues are. >>>>> >>>>> There is no single answer. You want mshtml debug channel for most >>>>> cases. >>>>> If >>>>> the problem is with embedding document in an app, then shdocvw is also >>>>> useful. If you have scripts that don't work (and we use jscript for >>>>> them), >>>>> then jscript debug channel is the answer. If you have a problem with >>>>> loading >>>>> document, I'd add urlmon,wininet channel. >>>> >>>> After some digging around, there appears to be some issues with the >>>> jscript.dll implementation: >>>> >>>> $ trace:jscript:DispatchEx_QueryInterface >>>> (0x1dad2d0)->(IID_IDispatchJS 0x33d5e8) >>>> $ trace:jscript:DispatchEx_AddRef (0x1dad2d0) ref=7 >>>> $ trace:jscript:prop_get L"SWFObject" ret {VT_EMPTY} >>>> $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=6 >>>> $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=5 >>>> $ fixme:jscript:new_expression_eval throw TypeError >>>> The new_expression_eval fixme is because V_VT(&constr) == VT_EMPTY. >>>> >>>> Now SWFObject is defined in a<script> file, but there are various >>>> script files. For example, given a html file containing: >>>> >>>> <script src="a.js"></script> >>>> <script src="b.js"></script> >>>> with a.js: >>>> >>>> function SWFObject() { this.x = 5; } >>>> >>>> and b.js: >>>> >>>> var swf = new SWFObject(); // appears to be erroring here >>>> alert(swf.x); >>>> Is this supported currently in Wine, or am I going down the wrong track? >>> >>> It's a known regression. A hack from bug 24365 should work around it. >> >> OK. Thanks. I'll use that to proceed on the issues with Big fish Games. > > That's all fine, but all this won't help with fixing Big Fish Games. I understand this -- I am thinking of improving things for when errors occur. > The > problem is probably somewhere else and the question is why the script takes > code path resulting in an exception (and even if it's supposed to do so, > current exception handling is probably good enough for it). The problem with the current wine tip is that 'fixme:jscript:new_expression_eval throw TypeError' line. Since this is triggered in the main script (not in a try ... catch block) it will not get handled properly. > BTW, the script seems to mess with a flash plugin, that won't work with > jscript as we'd have to handle ActiveX controls in MSHTML. That's a hard > problem. Aha! That is likely what is calling the TypeError fixme. >> a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function > > That's not the right place. See exception_test in api.js for exceptions > test. It's obviously not testing OnScriptError, but most tests should go > there. This is what step (1) is testing: exception_test(function() {new null;}, "TypeError", ...); which is great if you have something like: <script>try { new null; } catch (e) { ... }</script> but not something like: <script>new null;</script> This triggers (http://msdn.microsoft.com/en-us/library/shbz8x82%28v=VS.85%29.aspx) the IActiveScriptSite_OnScriptError callback notification. This is what I intend on testing in the dlls/jscript/tests/activex.c tests as I need to inspect that call when executing this type of unhandled/uncaught exception, which is what will happen in the Big Fish Games client. - Reece

Sept. 29, 2010

Re: mshtml and friends

by Jacek Caban

On 9/29/10 2:30 PM, Reece Dunn wrote: > On 29 September 2010 11:39, Jacek Caban<jacek(a)codeweavers.com> wrote: >> On 9/28/10 9:37 PM, Reece Dunn wrote: >>> On 28 September 2010 15:14, Jacek Caban<jacek(a)codeweavers.com> wrote: >>>>> I am interested in helping out to improve this area -- my aim is to >>>>> not require the `winetricks ie6` command to get some of these >>>>> applications (specifically the Big Fish Games client) to a usable >>>>> state. >>>>> >>>>> Therefore, I am wondering if anyone knows where the best place is to >>>>> start looking (e.g. known areas of missing functionality) or how to >>>>> debug applications (and interpret WINEDEBUG output) to identify where >>>>> the issues are. >>>> There is no single answer. You want mshtml debug channel for most cases. >>>> If >>>> the problem is with embedding document in an app, then shdocvw is also >>>> useful. If you have scripts that don't work (and we use jscript for >>>> them), >>>> then jscript debug channel is the answer. If you have a problem with >>>> loading >>>> document, I'd add urlmon,wininet channel. >>> After some digging around, there appears to be some issues with the >>> jscript.dll implementation: >>> >>> $ trace:jscript:DispatchEx_QueryInterface >>> (0x1dad2d0)->(IID_IDispatchJS 0x33d5e8) >>> $ trace:jscript:DispatchEx_AddRef (0x1dad2d0) ref=7 >>> $ trace:jscript:prop_get L"SWFObject" ret {VT_EMPTY} >>> $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=6 >>> $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=5 >>> $ fixme:jscript:new_expression_eval throw TypeError >>> The new_expression_eval fixme is because V_VT(&constr) == VT_EMPTY. >>> >>> Now SWFObject is defined in a<script> file, but there are various >>> script files. For example, given a html file containing: >>> >>> <script src="a.js"></script> >>> <script src="b.js"></script> >>> with a.js: >>> >>> function SWFObject() { this.x = 5; } >>> >>> and b.js: >>> >>> var swf = new SWFObject(); // appears to be erroring here >>> alert(swf.x); >>> Is this supported currently in Wine, or am I going down the wrong track? >> It's a known regression. A hack from bug 24365 should work around it. > OK. Thanks. I'll use that to proceed on the issues with Big fish Games. That's all fine, but all this won't help with fixing Big Fish Games. The problem is probably somewhere else and the question is why the script takes code path resulting in an exception (and even if it's supposed to do so, current exception handling is probably good enough for it). BTW, the script seems to mess with a flash plugin, that won't work with jscript as we'd have to handle ActiveX controls in MSHTML. That's a hard problem. > a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function That's not the right place. See exception_test in api.js for exceptions test. It's obviously not testing OnScriptError, but most tests should go there. Jacek

Sept. 29, 2010

Re: mshtml and friends

by Reece Dunn

On 29 September 2010 11:39, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 9/28/10 9:37 PM, Reece Dunn wrote: >> >> On 28 September 2010 15:14, Jacek Caban<jacek(a)codeweavers.com> wrote: >>>> >>>> I am interested in helping out to improve this area -- my aim is to >>>> not require the `winetricks ie6` command to get some of these >>>> applications (specifically the Big Fish Games client) to a usable >>>> state. >>>> >>>> Therefore, I am wondering if anyone knows where the best place is to >>>> start looking (e.g. known areas of missing functionality) or how to >>>> debug applications (and interpret WINEDEBUG output) to identify where >>>> the issues are. >>> >>> There is no single answer. You want mshtml debug channel for most cases. >>> If >>> the problem is with embedding document in an app, then shdocvw is also >>> useful. If you have scripts that don't work (and we use jscript for >>> them), >>> then jscript debug channel is the answer. If you have a problem with >>> loading >>> document, I'd add urlmon,wininet channel. >> >> After some digging around, there appears to be some issues with the >> jscript.dll implementation: >> >> $ trace:jscript:DispatchEx_QueryInterface >> (0x1dad2d0)->(IID_IDispatchJS 0x33d5e8) >> $ trace:jscript:DispatchEx_AddRef (0x1dad2d0) ref=7 >> $ trace:jscript:prop_get L"SWFObject" ret {VT_EMPTY} >> $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=6 >> $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=5 >> $ fixme:jscript:new_expression_eval throw TypeError >> The new_expression_eval fixme is because V_VT(&constr) == VT_EMPTY. >> >> Now SWFObject is defined in a<script> file, but there are various >> script files. For example, given a html file containing: >> >> <script src="a.js"></script> >> <script src="b.js"></script> >> with a.js: >> >> function SWFObject() { this.x = 5; } >> >> and b.js: >> >> var swf = new SWFObject(); // appears to be erroring here >> alert(swf.x); >> Is this supported currently in Wine, or am I going down the wrong track? > > It's a known regression. A hack from bug 24365 should work around it. OK. Thanks. I'll use that to proceed on the issues with Big fish Games. I am also planning on improving wine's behaviour in this regard on error (to assist in tracking down regressions/unimplemented behaviour). The details will likely change as I progress on this. Specifically: 1/ new_expression_eval @ dlls/jscript/engine.c -- FIXME: throw TypeError a/ add dlls/jscript/tests/api.js test -- 'new null;' throws TypeError b/ call throw_type_error @ dlls/jscript/error.c ==> I have a patch for this, just need to run it on winetestbot to verify Windows behaviour. 2/ Test unhandled exceptions when parsing scripts a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function b/ modify parse_script_a to support expected error code tests c/ call parse_script_a(script, "new null;", error) i/ thrown error -- throw TypeError(); ii/ unexpected -- new null; iii/ parse error -- new ; iv/ caught error does not call ActiveScriptSite_OnScriptError -- try { new null; } catch (e) {} d/ if FAILED(parse_script_a) i/ check if ActiveScriptSite_OnScriptError is called ii/ test values on IActiveScriptError object e/ implement calling ActiveScriptSite_OnScriptError in wine's jscript correctly 3/ ActiveScriptSite_OnScriptError @ dlls/mshtml/script.c a/ add dlls/mshtml/tests/script.c test ==> mshtml.ActiveScriptSite_OnScriptError fires an onerror event b/ implement the behaviour in wine 4/ Real-world test case: a/ add a new dlls/mshtml/tests/jserror.html file: <script> called_onerror = false; function trigger_error(){ throw SomeError(); } </script> <body onerror="called_onerror = true;" onload="trigger_error(); ok(called_onerror);"> </body> 5/ test/investigate the default mshtml onerror behaviour - Reece

Sept. 29, 2010