Patch for Wine audio destabilisation

For those who play SL via Wine to get audio, here is a patch that should reduce clicking and white noise crashes.

http://www.winehq.org/pipermail/wine-devel/2006-April/046683.html

Apply, run "autoheader; autoconf" then rerun configure, make, make install.

You'll need to mark wineserver as suid root for this, however, it will drop privs as soon as it starts so essentially nothing is running as root any longer, except that wineserver has CAP_SYS_NICE so it can raise the priority of the audio thread.

This patch may not be necessary for some people.

UPDATE: - Post new patch.

Wow! It's time we got a Developer Award here!

Thanks!!!

I've not had audio problems so haven't tried the patch, but nice work.

Running as root is quite an issue. How amenable is wine to running suid root? Perhaps, say, it could spawn a helper-thread (before giving up root privs like good suid apps should ) whose only job and capability is re-prioritising other threads. This would only happen if wine was installed suid-root.

IMHO it's not really a big issue - Windows programs are virtualised and do not have any understanding of what "root" is. The worst that could happen is they write outside of $HOME. Or in the case of time critical threads they could deadlock the machine, but, this would be a hang in Windows too and software that hangs a box really isn't that useful so is unlikely to be released.

That said, the principle of least privilege is a good one, and various approaches to not requiring root have been looked at. There's currently no consensus on the way forward, see the discusison on wine-devel to see this. Having Wine acquire the capability to use sched_setscheduler then drop privs might work.

On the contrary. Though many programs may not have an understanding of what "root" is, that is because they are designed to run with administrator privileges (the Windows equivalent of root).. so it's more like they don't have an understanding of what "a limited user" is. This is part of the reason why buggy Windows apps have a tendancy to hang, or severely pound on, the machine. Since Wine tries to reproduce Windows bug-for-bug, you wouldn't want a Windows program that hits said bug in Windows to also effect your Linux system just as bad through Wine. The raw bytecode is being executed, so you do *not* want it being run with root privs unless it needs it and you trust it (just as with any other Linux app). Wine simply allows Windows apps to run on Linux. All safety precautions you take with Linux apps, you should take with apps through Wine.

Not many programs use time critical threads (which is why this requires root on Linux), so the performance problems Windows programs have usually have other causes like poor kernel disk scheduling.

That said time critical threads are essential for robust audio whatever platform you work on. This is true on Linux as well, if you look at the JACK professional audio server it does exactly what this patch does for Wine.



I agree, but I think it's important to realistically weigh the risks. The root vs user distinction is not designed for desktop security and comes out of timesharing mainframe systems in the 60s/70s, was carried forward into the corporate LAN and has kind of trickled down into the desktop from there.

Consider this - a Linux program can, without needing root access:

* send spam
* force itself to load at startup
* display adverts
* intercept secure form submissions (eg bank login details) before they are encrypted
* make itself hard to kill or remove
* try and intercept the root password as it's being typed into a graphical authentication window

And these are all the characteristics of malware that cause Windows users problems today. Some things that require root access on Linux:

* beeping the PC speaker
* running traceroute
* mounting removable media
* creating robust/low-latency audio streams

Which makes sense for multi-user servers but not for the desktop. Most of these are "solved" by distributions using root daemons and suid root binaries anyway.

So I don't think this is really a good security system. We have the ability to do better via SELinux and AppArmor, but so far nobody has worked on this problem space much.

If you are concerned about a Windows program writing outside of $HOME just remove the Z: drive mapping from the configuration using the winecfg tool. Unless the Windows program in question knows it might be running in Wine and does direct syscalls (I've never heard of such a thing ...) it cannot escape from the virtualized "jail".

This sounds like a job for capabilities(7), right? You'd still need some kind of root access (setuid root wine for example), but the process could keep just CAP_SYS_NICE while switching back to the real uid, which seems more secure.

The way capabilites was designed, instead of making wine setuid root you'd just put an extended attribute in the filesystem saying that wine is supposed to have CAP_SYS_NICE regardless of who executes it, but this hasn't been implemented in Linux yet.

The weaknesses of having a root user in a system are addressed by plan9, a rewrite from scratch of unix. A lot of stuff is actively being migrated to linux, but I don't think they will get it ALL in.

However, the point is well taken: I cannot kill the SYSTEM with my non-root user, but I can wipe out all my files And so can a rogue process running with my uid ...

If you want real security, its knoppix or another Live CD.

Yeah, something like that. I'm not entirely sure that CAP_SYS_NICE lets you change scheduler on threads as well as processes - it's hard to find accurate info on this using Google because LinuxThreads and NPTL differ so much at this level. Paul Davis would know.

Wow... I usually run the native client, but I got a new toy today and wanted to get it's full effect a bit (i.e. sound). So I patched WINE with this patch as well as the OpenGL/WGL patch from another thread here and let me just say.... SL runs fantastically via WINE like this. It's nice to have uploading, sound, normal copy/paste, etc. I am running smoothly, averaging 18-25 FPS when "doing stuff" in SL.

The only problem left really is the alpha channel stuff. If or or other change clothes or something, in rolls the black tar look, heh.

Cannot wait until the native client gets more feature-rich and it will still likely be my primary use client, this is nice when need be.

--Val

I've now implemented this. Wine drops privs at startup whilst keeping CAP_SYS_NICE. So, it's easier to use and more secure now. You just have to run chmod +s `which wineserver`

Following the lead of an earlier post in a different thread I've uploaded binaries for wineserver which are binaries generated with the above source patch. They can be found here http://zi.furhome.net/unsorted. The MD5sum for the binaries are as follows:

62350248dadf1e174527a1efd4a04e24 wineserver-0.9.16
3ee6c8c57d80e8ca491cc7f013e6fcdd wineserver-0.9.17

Find out your version of wine: wine --version
Copy the appropriate binary to the location of wineserver and chmod +s
e.g:
sudo cp wineserver-0.9.16 /usr/bin/wineserver
sudo chmod +sx /usr/bin/wineserver

It may also be necessary to chown the wineserver binary to the username you are running wine/SL under.

Damn. That's the best we can do? O.o There's NO WAY IN HELL I am running any Windows application as root. Never. Not on your life. It's not what it might take advantage of, but what it might screw up because...well, it is written for a non-operating-system.

There's got to be a better solution here. I know SL doesn't work with Wine 0.9.17. Has anyone run with the development version of Wine and seen any better/different sound performance?

0.9.18 has been out for over a week, and 0.9.19 came out today. Apply his patch, don't run anything as root... works great for me.

--Val