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.