[ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

[Con Kolivas]

Mike Hearn wrote:
>>> Other solution is just to detect this and ask the user to rerun Wine 
>>> as root. I don't think that'd be a big deal.
>>
>>
>>
>> But then that brings up the issue of users not being able to run wine
>> merely because they don't have root access, i.e. users on a Linux system
>> in a business environment, or remote X/telnet access on a server with
>> wine (for various reasons).
> 
> 
> These people probably wouldn't be running scheduling sensitive tasks.
> 
>> The idea of having to run under root was one of the ones why people
>> avoid SVGAlib nowadays, and setuid/root will be a deep security risk
>> considering what kind of apps we're looking at here.  If we say, run
>> notepad, we have a root editor application -- capable of messing with
>> config files on the Linux setup -- something that the Linux admin might
>> not want.
> 
> 
> You can make Wine suid root and then sandbox it back down to standard 
> user level privs + scheduling using SELinux, so it'd only be a security 
> "problem" for a short while.
> 
> Given that we know of no Windows apps self-aware enough to escape the 
> emulation I don't even see what security problems it can cause on home 
> machines where the user has root access anyway. I guess if you got owned 
> via Internet Explorer or something it would give attackers access to 
> your configuration files but the chances of this happening and being 
> taken advantage of are tiny.

I wouldn't trust it. An app just misbehaving can trash important parts 
of your filesystem. Suid root is just a bad idea, windows being linux 
aware or not. Just for mild amusement I think someone being funky got a 
windows virus to work under wine if I recall correctly.

> 
>> If this is implemented, shouldn't this be a warning, not a forced 
>> thing? So that a normal user could (try and) run wine without root 
>> access?  And
>> I presume that this would be 2.6 specific detection - otherwise, there's
>> not really a need (since Wine worked OK under 2.4 and such).  We could
>> say something like: "Wine has dectected that you are running Wine as a
>> normal user under Linux kernel 2.6+.  Due to changes in the scheduling
>> mechanism in 2.6, which includes preempting and a change in the way
>> process priorities are handled, Wine may not work properly, or different
>> parts may work at different speeds, causing desyncronization of your
>> application and/or it's components.  You are suggested to <(run wine as
>> root) or (downgrade and use a (2.4 kernel) AND/OR <supported kernels
>> list>) or (list other workaround information)>."
> 
> 
> Well, ideally it'd be only displayed when we detected a mismatch between 
> the apps requirements and the underlying kernel scheduling. Which may 
> not even exist: we haven't *proven* anything yet, just thrown theories 
> around. Unfortunately the people most qualified to diagnose the problem 
> are all as much in the dark as we are :(

You should not renice any user applications -nice. The only solution is 
to run the less important ones +nice. Also, if you renice something from 
wine to better priority than X you will almost certainly have worse 
behaviour, not better, because X is almost always seen as consuming as 
much cpu as you give it thus being lower priority than a wine app that 
does any sleeping. Feel free to try it; you'll see performance gets 
worse as the nice value is less nice than X. Recall this email thread 
started with nice+19 being a workaround, not the other way around.

> Random point: the wording of that warning is terrible I'm afraid :) 
> There's no way we could ever throw such a complex message in the users 
> face, nobody would understand it! A much better way to word such a 
> message would be:
> 
> "In order for this program to run correctly, you must run Wine with root 
> priviledges. The program will proceed but you may notice audio 
> stuttering or performance problems."
> 
> Even that's not ideal. It requires the user to:
> 
> a) Understand the concept of root == administrator user that should not 
> normally be used, which is a non obvious mapping. It's one of those 
> things you just "have to know", and we're trying to cut the number of 
> these things as much as possible.
> 
> b) Understand what Wine is - obviously we can't get away from this 
> entirely but long term I'd like to see Wine become just another Linux 
> subsystem that does its job so well the user doesn't ever notice it
> 
> c) Understand *how* to run Wine with root privs. If you just su to root 
> and run it, you can't start your app as you're now running with a 
> different virtual Windows drive and registry. It's really not obvious 
> how to do this even for experienced Linux users (answer, set WINEPREFIX)
> 
> Anyway. That's todays usability lecture over with :)

Agreed. Nonetheless I think this is the wrong approach.

>> I presume that if someone wanted to get started writing a patch now
>> using any one of these ideas, then we could just test it and see how it
>> does among us, and then if it's okay, submit it, get it through CVS, see
>> what happens, get it through a release if that happens, and then we can
>> finish this debate only when performance issues or something else needs
>> to be done about this.
> 
> 
> I think we should get a much clearer idea of what's going wrong here 
> first before trying to write patches or get code into CVS.

Agreed; recall this was not all versions of wine that were proven to be 
affected.

This will all change as Xorg matures though so we may have to rethink 
everything. Keith Packard has explained that X that currently uses cpu 
is doing precisely nothing during that cpu time. It is spinning just 
waiting for the graphics cards' gpu to do the work. This is ancient 
behaviour from X that we still have that is done to represent the fact 
that X is busy and is as far as I'm concerned the single most important 
change required to improve graphics performance in linux.

Cheers,
Con
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20040903/2bbbe49e/signature.pgp