October 2002 - Wine-Devel - list.winehq.org

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 01:21 pm, Alexandre Julliard wrote: > Sometime in June, I don't have the exact date of the first release > unfortunately. Release 0.0.2 was on June 25. Too far away for 0.8, too close for 1.0. Maybe 0.9, if we're lucky. -- Dimi.

Oct. 31, 2002

Re: winapi_check question...

by Greg Turner

On Thursday 31 October 2002 12:54 pm, Patrik Stridvall wrote: > Greg wrote: > > On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote: > > > Ignore it. > > > > OK. You promise it won't screw up the actual documentation bot? > > Promise? Hmm. All code have bugs you know and winapi_check is > designed to be ad hoc and thus inherently buggy... :-) > > But seriously, I wouldn't worry about it. BUT I CANT SLEEP!!!! (j/k, it's already forgotten) > Anyway. A real fix to the code you be nice. but I /am/ being nice ;) > Presumable the type CLIENT_CALL_RETURN haven't > been declared properly. no can do, it's that way because of an obscure gcc vs. msvc call convention mismatch for function calls with struct return-types. anyhow, CLIENT_CALL_RETURN is just a stupid union for casting between longs and ptr's, so, to me, it's just not worth the effort to understand the problem. Basically, I just did what Alexandre told me to, and called it "fixed" :) A real fix probably involves some crazy wrapper/thunking technique, assembly code, wierd gcc command-line options, an extention to the .spec format, and/or obscure #pragma's -- quite possibly beyond my abilities, and definitely beyond my level of motivation, given the (presumed) non-severity of this particular instance of the problem... maybe, however, there are some more pressing reasons to solve this, in which case I'd be happy to look at it a bit more carefully (but still skeptical of my ability to solve it). -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Dimitrie O. Paun

On October 31, 2002 01:46 pm, Greg Turner wrote: > In support of attached patches: Most are irrelevant. The point is not to transport the patch to Alexandre. If so, you might as well send it directly to him. Point is to get peer review, and maybe comments. For this purpose, inlining the patch is the preferred methods, hands down. Reasons have been hashed already multiple time, please read the archives. There are good reasons why people with a lot of experience handling patches (e.g. Alexandre, Linus, etc.) prefer this method. -- Dimi.

Oct. 31, 2002

Re: Wine securityflaw.

by David Fraser

Geoff Thorpe wrote: >On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote: > > >>On Thursday 31 October 2002 08:10 am, Raul Dias wrote: >> >> >>>My $0.02, >>> >>>A way to make it more secure is to catch key API calls and decide if >>>the application is allowed to run it or not. >>> >>> >>not a bad idea. >> >> >> >>>Wine could implement a clean Security Layer: YES >>> >>> >>Clean, perhaps, but secure? That depends on what you are trying to >>achieve: since the unix API is available to apps running under wine, >> >> > >This subject interests me a great deal so please humour me as I try to >wrap my head around the wine-specifics well enough to get an >accurate(ish) picture of this. I'm a security person, but no win32 >expert and even less of a PE/ELF hacker... > >First I can understand the point made that, at the end of the day, the >only *actual* security you can force on a wine-loaded application is >whatever security the operating system forces on *all* applications >(wine-loaded or otherwise) running as the same user. Ie. even if a win32 >application loaded under wine couldn't directly call ioctl(), unlink(), >or fopen(), the binary code could still *reimplement* those functions in >assembly. I also realise that other assembly hacks (or just >trail-and-error "luck" virii) could scan the process's memory space >looking for likely function pointers, file-descriptors, etc and start >meddling with them directly to bypass the wine-implemented win32 API. >Does that seem a reasonable understanding of the situation? > >My next question is this: why is the unix API available to >wine-loaded PE apps/libs? I can't see a single compelling reason for >this, though I'm prepared to be illuminated otherwise. If we discard >memory-scanning and other assembly tricks for a moment and consider just >the case of PE apps/libs generated from "clean C" (and "clean >compilers"); then preventing any direct binding of any wine-loaded PE >images to native ELF images, *except* those implemented by wine, >immediately raises the bar. Of course, I'm assuming this is *possible* >with the PE (and ELF) format(s)? > >My problem with discarding the "clean" security layer because it isn't >perfectly impenetrable in a technical sense, is that it is purely an >abstract technical-only view of things, and Wine's role (and >threat-model for its future success) is anything but purely technical. >Jeremy, I'd be particularly interested if you have any thoughts on this. >AFAICS, this idea is not just a question of security by obscurity - >there are technical and "political" issues involved too. > >First, not linking PE images to non-wine ELF images allows one to define >a security policy in wine for win32/PE executable code akin to a "rules >for Win32 programs" config. One possibility here is the kind of thing >Raul was discussing. Buggy programs aren't programs that try to detect >if they're running in wine and if so do damage - buggy programs are >programs using the win32 API written by careless win32 bunnies. *Those* >programs could be subject to a policy configuration that would allow you >to selectively restrict things in a way that will *always* be better >than what MS-windows provides - whether the programs are horribly buggy >or really solid. In other words, a configurable real-world >control/protection against potentially buggy win32 code (that would be >equally buggy on MS-windows and Wine after all). > >Second, if the PE loader doesn't blindly link PE apps/libs to native >libraries, then bypassing the wine-implemented win32 API (and thus the >policy configuration) would require an *explicit* workaround on the part >of the programmer. Putting in assembly code to prime registers and fire >interrupts that (a) on linux would getenv("HOME") and unlink() the >result, and (b) on windows would probably just crash with a BSOD is what >the security community call a "virus". :-) It doesn't have to be >difficult for the programmer to do it, it just has to require him/her to >be malicious and unambiguously *intend* to do it. Writing and >distributing one of these things opens you up to criminal prosecution in >many jurisdictions, and also allows McAfee and friends to assign a >signature to corresponding binaries and get them classified as a virus >(and their authors classified as bad people). > >Or put another way - as Wine converges on "beta" or "release" level and >Wine + XXX/OS (where XXX=Linux,FreeBSD,etc) becomes not only a >competitor to MS-windows, but in fact offers considerable advantages, >where then will the *threats* to wine lie?? I would certainly like to >(a) see the flexibility of being able to apply a "soft" security policy >for win32 applications in the wine-implemented win32 API, (b) force >win32 developers who are "anti-wine" and "pro-monopoly" to have to >expose themselves to criminal possibilites if they want to bypass >wine-based execution configuration and controls (or worse, if they want >to package anti-wine trojans). > > > >>So, for example, this could be used to protect a system against >>security flaws in Internet Exploder or Outlook... but a malicious virus >>writer could work around winapi-based security provisions, as discussed >>earlier in this thread. >> >> > >Yes, and I think the point that's worth making is that writing a >malicious virus against wine is not only a crime in the sense that >normal virus-writing is a crime, but also has >anti-trust/anti-competition overtones ... when you try to imagine which >companies would most like their win32-based applications to *NOT* run on >wine (and perhaps even hurt wine users), you might understand where I'm >coming from. > >In lieu of "pure" security enforcements (which would require >virtualisation anyway which Wine is not in the business of), I think a >"win32-API-based" security approach is worthwhile. If I can write win32 >apps that link directly to libc, I could elect to replace the >file-management subsystem of my app with a POSIXy layer that is only >used on wine "for performance reasons only, honest!". This would mean >(a) Wine's file-system configuration can be bypassed, and (b) I could >(perhaps deliberately) embed nasty corruption bugs in my POSIX subsystem >but have my win32 subsystem very stable. This program would just be >"unstable on wine" but not "anti-competitive" nor "criminal". But if you >don't let applications do this in wine's PE-loader (or at least let it >be controllable in the config) then acheiving the same result would >require me to write a genuine virus instead (and so open myself to >anti-trust/criminal accusations). > >Thoughts? > >Cheers, >Geoff > > I think this is missing the point. The way to make something secure isn't to make big software companies worry about anti-trust, or virus writers worry they might get sued for writing a virus. Big companies aren't likely to write wine-specific special workarounds that do nasty things, and virus writers couldn't care less. Any security improvements should be normal UNIX ideas like letting a wineserver do certain priviledged tasks running as a special user, while standard wine programs run as a different, non-priviledged user. In other words, the kernel layer in Windows should have higher priveledges than standard user processes, but not run as root. David

Oct. 31, 2002

Re: SetWindowHookEx

by Shachar Shemesh

I sent Alexandre the App privately. I originally wanted to CC the list (the app can be distributed under either GPL or LGPL), but the mail was rejected. I would hereby like to appologize for trying to attach more than the set limit of 40Kb of a zip file to the list. My appologies. In leu of such atrocities which I would not like to commit, and I would like to thank the moderator for stopping that mail, I have placed on a web site, and am hereby making both source and a compiled binary available in a zip file (no wonder it was more than 40Kb, what was I thinking trying to send it to the list) at http://www.consumer.org.il/personal/xeyes.zip. D/L size is 49Kb. Thanks, Shachar Alexandre Julliard wrote: >Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: > > > >>So you mean to say that my windows X-Eyes implementation won't work on >>WINE????? Damn. >> >>Anyone knows of any Unix port of that program? >> >> Shachar >> >>No, wait. I'm using a mouse hook. Maybe it'll work after all. >> >> > >At this point probably not, but if you could send me that app I'd be >interested to play with it. > > >

Oct. 31, 2002

Re: So lets say we do it

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On October 31, 2002 11:24 am, Alexandre Julliard wrote: > > First it doesn't even start because they don't have a config file. OK, > > Hear, hear! BTW, we should move configuration out of documentation/samples I don't think that would really help rpm users... IMO the whole concept is flawed (try editing the config while the wineserver is still running ;) configuration should be stored in the registry and there should be control panel applets to configure the various parts of Wine, which would allow changing things on the fly. Once we have that we need to make sure we have suitable defaults to allow running at least the drives/paths control panel without registry files at all. We also need the Wine dlls to register themselves instead of having to merge winedefault.reg by hand. Then it should be possible to write a .inf script to setup a new Wine install automatically from scratch. -- Alexandre Julliard julliard(a)winehq.com

Oct. 31, 2002

RE: winapi_check question...

by Patrik Stridvall

> On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote: > > Greg wrote: > > > winapi_check tells me: > > > > > > ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV > > > NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 > > > documentation: \ > > > /* CLIENT_CALL_RETURN */ > > > > This is because winapi_check misparser the line: > > LONG_PTR /* CLIENT_CALL_RETURN */ > > RPCRT4_NdrClientCall2(PMIDL_STUB_DESC pStubDesc, PFORMAT_STRING > > pFormat, va_list args) > > > > Ignore it. > > OK. You promise it won't screw up the actual documentation bot? Promise? Hmm. All code have bugs you know and winapi_check is designed to be ad hoc and thus inherently buggy... :-) But seriously, I wouldn't worry about it. Anyway. A real fix to the code you be nice. Presumable the type CLIENT_CALL_RETURN haven't been declared properly. > > > how shall I deal with these? > > > > Fix them as above or do as everybody elses do wait for me to fix it. > > :-) > > heh. Well, maybe I can set an example for those deadbeats :) :-)

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Greg Turner

On Thursday 31 October 2002 12:04 pm, Jaco Greeff wrote: > On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes > > And plain inlined patches are preferred against attachments. Just rabble-rousing here, but, until Alexandre stops accepting them, I plan to attach all my patches. I /am/ willing to mark them as "prefer inline display" or whatever it's called, which my mailer lets me do, but personally, I prefer not even to do this unless they're very, very small (one hunk). Since I've been doing lots of bullet-lists lately, here's a couple more: In support of attached patches: o Easier to separate out and organize in a filesystem o Less likely to munge international characters o No possibility to confuse carriage-returns from the e-mail with carriage-returns from the patch o Easier to view with syntax highlighting o Usually not automatically included in replies o Specifies a file-name for the patch o Doesn't /ever/ line-wrap (!) o No cut-and-paste to apply the patch o Allows us to turn on auto-line wrapping in our e-mail clients, which, in turn, makes wine-devel more readable (sometimes). o pretty icons in some clients ;) In support of inline patches o easier to read for some people I say, tough cookies. Stop using elm (or yahoo) and get a real reader :P (evil haloween laughter) -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

Re: SIGSEGV in IDirectDrawImpl_EnumDisplayModes

by Lionel Ulmer

> Sorry, that was the method I posted, I happened to paste the wrong function > name; this is the entire function with line 852 marked: Care to give me the actual data type of 'mp_directDraw' ? It seems that as you supposed, it does not use the correct function pointer when you use 'mp_directDraw->CreateSurface' and call instead 'EnumDisplayModes' thus, of course, leading to a crash as the callback function is not filled in properly. The only thing I find strange is that you call CreateSurface with the 3rd argument being NULL and we should see that in the trace for 'EnumDisplayModes'... Lionel -- Lionel Ulmer - http://www.bbrox.org/

Oct. 31, 2002

Re: So lets say we do it

by Rick Romero

On Thu, 2002-10-31 at 12:19, Dimitrie O. Paun wrote: > On October 31, 2002 11:24 am, Alexandre Julliard wrote: > > You forgot a few things here: > > > [...] it doesn't work because the drives are wrong. > > Yep. wineinstall? > > > Then they don't have the proper registry (winedefault.reg? what's that?) > > :))) > I hate to jump in again, but isn't wine a little backwards from other releases when dealing with a fresh tar.gz install? I realize wineinstall will do the work for you, but aren't people just used to ./configure - make - make install? I think they do that, then they're stuck. configure always tells you to do a 'make depend && make', why not throw in a little blrub "Hey, if you're running this for the first time, run wineinstall instead." ? Or is wineinstall not doing what I think it is (setting up initial environment)? Ok, I'll be quiet for a few months again :) Rick > -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

Oct. 31, 2002