Audio stuttering issue

Chris chris.kcat at gmail.com
Sat Jul 29 16:11:55 CDT 2006


On Saturday 29 July 2006 09:01, Mike Hearn wrote:
> On Thu, 27 Jul 2006 15:05:12 -0700, Chris wrote:
> > It does. You don't really have to change anything.
>
> I thought the user would have to change the limit in their startup scripts
> or the like?

I mean you don't need to change your patch at all. :) The user's going have to 
do something one way or the other.. either setting the suid-root bit and 
constantly re-chown'ing /tmp/wine-*, or setting a non-0 RLIMIT_RTPRIO value. 
The latter only needs to be done once, and is completely at the user's 
descretion at any time.

> Well, using the suid-root bit seems more secure than this ... the limit
> allows any application to gain realtime privs easily whereas having wine
> acquire CAP_SYS_NICE means only Windows apps can get it (or rather it's
> very hard for other apps to use Wine to get it).

Though setting the suid-root bit means Windows apps will *always* be able to 
get realtime priority if they want, regardless of the app, whereas using the 
RLIMIT_RTPRIO value will let users decide, on a per-user basis, and further 
only when they want (running a trusted program? set it to 1 - 99 and run 
wine; not a trusted program? set it to 0 then run wine). Since there's 
different values, if another (root) process has higher priority, it's still 
able to interrupt the app. And if worse-comes-to-worse, there's always 
alt-sysrq-k.

If the goal is to match Windows feature-for-feature and bug-for-bug, this 
seems like a nice way to get that feature while still retaining some 
security. And if you're trying to blend Windows apps transparently with X 
apps, RLIMIT_RTPRIO is there for all apps to use on Linux.



More information about the wine-devel mailing list