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