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