On Sun, Apr 02, 2006 at 08:57:28PM +0200, Alexandre Julliard wrote: > Mike Hearn <[EMAIL PROTECTED]> writes: > > > I'm not sure it counts as easy. At least Fedora and SUSE already have an > > LSM module loaded, for SELinux and AppArmor respectively. Some solution > > based on making wineserver suid root might work but I didn't get anywhere > > when I played with that. > > You're missing the point. The problem is not "how can we bypass system > protections?", the problem is "how can we achieve what we want without > having to bypass anything?". These things are restricted to root > precisely because they can screw up the system, and that's not a power > we want to give to random Win32 apps. What we need is a mechanism that > is safe enough to be enabled by default on all systems, without > requiring suid root or similar hacks.
It does work without any special privileges on a kernel with the SCHED_ISO patch (included in -ck), because it can transparently exchanges SCHED_FIFO/RT with SCHED_ISO. A thread with SCHED_ISO can not outstarve the system because when using over 80% (default) cpu it's priority handling is revoked. It also works fine on any system on that wine got the permission for SCHED_FIFO/RT, because when an App. behaves wrong (it's thread outstarves the rest of the system) a user can hit the magic-sysrq key combo for "disable SCHED_FIFO/RT for running processes". (I'm not sure if that magic-sysrq-key is available in mainline yet or only in -ck. Also note that on windows a base priority this high is able to outstarve the the system.) About the "SCHED_FIFO/RT needs root"-problem: It does not. I think since Linux kernel 2.6.12 there is a new resource limit for realtime (think: ulimit). There are various ways to give wine an increased limit. Among them a suid helper called set_rlimits and using a up to date version of pam (newer version can set this limit). This is perhaps less critical than the process limit, which is I think per default on a Debian unlimited (think: fork bomb). This also seems to be _the_ solution for this problem in the (audio-)linux community. So trying to use SCHED_FIFO and if it fails trying to use SCHED_ISO is safe for every system. (Not sure if that is the best order. A more complete patch would probably also take care of most of the other base priorities windows has by using SCHED_IDLE... SCHED_WINE anyone?) If the user chose to permit SCHED_FIFO/RT he is probably willing to risk needing to hit that magic-sysrq-key to disable it again. If he does not want to risk that he can use a kernel with SCHED_ISO. Does this fit your requirement? Jan
