Jan Zerebecki wrote:
On Sun, Apr 02, 2006 at 08:57:28PM +0200, Alexandre Julliard wrote:
Mike Hearn mike@plan99.net 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
oh-la-la, very nice! This is a great idea, and we should work on it. And hopefully the SCHED_ISO patch get into the main kernel tree soon, cause the hourly openssl, or vmware, or running 7 simultaneous compiles that literally give the system the slashdot effect really get on my nerves....