November 2009 - Wine-Devel - list.winehq.org

Re: Another article that makes me want Wine to run in a sandbox

by David Gerard

2009/11/8 Dan Kegel <dank(a)kegel.com>: > On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein <shacklein(a)gmail.com> wrote: >> I believe the type of sandboxing being discussed includes things like >> preventing Win32 apps from breaking out into native calls using the >> infamous interrupt trick. Correct me if I'm wrong though :) > No, I was thinking of native sandboxing, so even if they did > manage to make native calls, they couldn't do any harm. > Running as another uid is a fine example of a native sandboxing > technique. (So, on a single user system, you could have a > uid dedicated to running sandboxed apps, and it would be > unable to affect the regular user's data.) This would > only be useful for apps that don't need to load or save user data > (probably), for example, for casual games. Yes, Unix comes with pretty good sandboxing built-in in the form of separate user names. Then one could explicity open communication channels between the Unix environment and the Wine user, rather than trying to close off open-everything. Fairly obviously, it'll take some pretty substantial real-world need for this to get anywhere near the winehq tree! But it's an interesting idea. Imagine, successfully securiing Win32 ... - d.

Nov. 8, 2009

What to do when un-nominating bugs for 1.2

by Dan Kegel

In the gcc world, when a bug is targeted for release X and doesn't make it in time, it is retargeted for release X+1. So when 1.0 rolled around, I retargeted the leftover 1.0-targeted bugs at 1.2. Can we do the same this time, and retarget 1.2 bugs for 1.4 if they're not going to be fixed for 1.2? The only time one should simply remove the 1.2 target is if we decide the bug really isn't even a candidate for 1.4 (or was nominated for 1.2 in error).

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by Dan Kegel

On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein <shacklein(a)gmail.com> wrote: > I believe the type of sandboxing being discussed includes things like > preventing Win32 apps from breaking out into native calls using the > infamous interrupt trick. Correct me if I'm wrong though :) No, I was thinking of native sandboxing, so even if they did manage to make native calls, they couldn't do any harm. Running as another uid is a fine example of a native sandboxing technique. (So, on a single user system, you could have a uid dedicated to running sandboxed apps, and it would be unable to affect the regular user's data.) This would only be useful for apps that don't need to load or save user data (probably), for example, for casual games.

Nov. 8, 2009

Re: The user32/win test crashes X on Intel cards

by Francois Gouget

On Sun, 8 Nov 2009, Francois Gouget wrote: [...] > Here's my configuration: > * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 > * VideoRAM: 256MB (according to /var/log/Xorg.0.log) > * xserver-xorg-video-intel 2:2.9.0-1 > Latest from Debian Testing. > Debian Unstable does not seem to have a more recent driver. More data: * Marcus is running version 2.9.1 of the Intel driver (and gets the crash). * Michael Stefaniuc does not have the problem. He is using FC11's 2.8.0 version of the driver. * I tried Michael's FC11 intel_drv.so file on my system and I still get a crash. I also tried the 2.8.1 Ubuntu driver and got the same result. So the problem comes from some other part of Xorg or the kernel. * Michael is running the 2.6.32 kernel and I'm running the 2.6.30 one. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Nov. 8, 2009

Re: The user32/win test crashes X on Intel cards

by Charles Davis

Francois Gouget wrote: > I hit this issue while trying to run winetest for WineConf. I looked > into it and the crash is caused by this line in dlls/user32/tests/win.c: > > SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); > > More precisely it's the setting of the window width and height to > 32768 x 40000 that causes the crash. Looking at the .xsession-errors > file I see the window manager reporting the following X server error: > > Anomalie dans le gestionnaire de fenêtres : Unexpected X error: BadAlloc > (insufficient resources for operation) serial 11940 error_code 11 > request_code 53 minor_code 0) > > Is it possible that this is just an out of memory issue caused by the > huge window size? According to my tests 32000x32000 (a tad < 3GB) works > but 32767x32767 (a tad >3GB) cause the crash. > > Here's my configuration: > * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 > * VideoRAM: 256MB (according to /var/log/Xorg.0.log) > * xserver-xorg-video-intel 2:2.9.0-1 > Latest from Debian Testing. > Debian Unstable does not seem to have a more recent driver. > > Marcus got the same issue and he had an Intel card too and we were the > only two with this issue. So apparently this is Intel-specific. > > Does any one have an Intel card where this does not happen? What's your > driver version? > > > > ------------------------------------------------------------------------ > > This happens on Mac OS X, too. Check out http://xquartz.macosforge.org/trac/ticket/293 Chip

Nov. 8, 2009

Re: d3d9: quiet a few very noisy fixme's

by Stefan Dösinger

Am 08.11.2009 um 13:28 schrieb Austin English: > On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders > <xerox_xerox2000(a)yahoo.co.uk> wrote: >> These are spawned at huge rate in World in Conflict demo >> (http://bugs.winehq.org/show_bug.cgi?id=11114) > > It'd be quicker/cleaner to just change them to warn's instead, IMHO. I think BeginEvent / EndEvent can be changed to TRACE's. They're tools for Microsoft's debugger and profile apps - so the main purpose of them is to help debugging. The shader validator one should probably be a one-time FIXME

Nov. 8, 2009

Re: d3d9: quiet a few very noisy fixme's

by Austin English

On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > These are spawned at huge rate in World in Conflict demo > (http://bugs.winehq.org/show_bug.cgi?id=11114) It'd be quicker/cleaner to just change them to warn's instead, IMHO. -- -Austin

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by Ben Klein

2009/11/8 David Gerard <dgerard(a)gmail.com>: > You'd get good sandboxing running Wine apps as another user. Main > problem then is integration with the user's desktop. Doable, but a > nuisance. Not really. A separate Wine user wouldn't prevent people from running Wine as root incorrectly, and if you integrate it with the normal user's home directory, it's no longer sandboxed (or at least, no more than separated wineprefixes). I believe the type of sandboxing being discussed includes things like preventing Win32 apps from breaking out into native calls using the infamous interrupt trick. Correct me if I'm wrong though :)

Nov. 8, 2009

The user32/win test crashes X on Intel cards

by Francois Gouget

I hit this issue while trying to run winetest for WineConf. I looked into it and the crash is caused by this line in dlls/user32/tests/win.c: SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); More precisely it's the setting of the window width and height to 32768 x 40000 that causes the crash. Looking at the .xsession-errors file I see the window manager reporting the following X server error: Anomalie dans le gestionnaire de fenêtres : Unexpected X error: BadAlloc (insufficient resources for operation) serial 11940 error_code 11 request_code 53 minor_code 0) Is it possible that this is just an out of memory issue caused by the huge window size? According to my tests 32000x32000 (a tad < 3GB) works but 32767x32767 (a tad >3GB) cause the crash. Here's my configuration: * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 * VideoRAM: 256MB (according to /var/log/Xorg.0.log) * xserver-xorg-video-intel 2:2.9.0-1 Latest from Debian Testing. Debian Unstable does not seem to have a more recent driver. Marcus got the same issue and he had an Intel card too and we were the only two with this issue. So apparently this is Intel-specific. Does any one have an Intel card where this does not happen? What's your driver version? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by David Gerard

2009/11/8 Dan Kegel <dank(a)kegel.com>: > I expect that people will do utterly stupid things, > there's no two ways around that, it's human nature. > That being the case, I think there are still opportunities > for providing a safe computing experience without > compromising the user's convenience. > Case in point: the sandbox used by the Chromium web > browser. It provides a modicum of security without > getting in the way. I can easily imagine classes > of windows apps, say, games, fitting nicely into a > sandboxed wine environment. Sure, getting the > networking right would be a challenge, but for at > least casual games, it ought to be quite doable. > The key is to require no user choices -- just do the > right thing by default. Then the user's level of education > or computer skills don't matter. You'd get good sandboxing running Wine apps as another user. Main problem then is integration with the user's desktop. Doable, but a nuisance. - d.

Nov. 8, 2009