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

[Mike Hearn]

>>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.

> 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 :(

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 :)

> 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.

thanks -mike