real SetProcessClass and SetThreadPriority support
Are there any plans or is anyone working on mapping Windows SetProcessClass and SetThreadPriority support to linux process priorities on kernels that support CAP_SYS_NICE?
Robert Reif wrote:
Are there any plans or is anyone working on mapping Windows SetProcessClass and SetThreadPriority support to linux process priorities on kernels that support CAP_SYS_NICE?
Mapping Win32 thread priority levels to Linux nice levels is fairly trivial, but convincing kernel developers to allow unprivileged user-space programs to control thread priorities is the big problem. The last time a discussion like this came up, we (Wine developers and Cedega developers) requested a way of changing a thread's relative priority within a process (without affecting the overall CPU time the process gets). This should be a good compromise between meeting applications' needs and preventing unprivileged applications from freezing the computer. AFAIK, this hasn't been implemented yet. Rob
On Wed, 6 Apr 2005 14:04, Robert Shearman wrote:
The last time a discussion like this came up, we (Wine developers and Cedega developers) requested a way of changing a thread's relative priority within a process (without affecting the overall CPU time the process gets)
This is far from trivial to implement in the kernel - I wouldn't count on it happening in anything approaching a reasonable time frame, and I'd bet against it being done at all. If we want to be able to increase the priority of a thread, I suspect that the only reasonable way to do so (that stands a chance of being done) will be by means of either a helper process that runs as root or a kernel module, and I would lean towards the helper process as being the preferable solution.
Robert Shearman wrote:
Robert Reif wrote:
Are there any plans or is anyone working on mapping Windows SetProcessClass and SetThreadPriority support to linux process priorities on kernels that support CAP_SYS_NICE?
Mapping Win32 thread priority levels to Linux nice levels is fairly trivial, but convincing kernel developers to allow unprivileged user-space programs to control thread priorities is the big problem. The last time a discussion like this came up, we (Wine developers and Cedega developers) requested a way of changing a thread's relative priority within a process (without affecting the overall CPU time the process gets). This should be a good compromise between meeting applications' needs and preventing unprivileged applications from freezing the computer. AFAIK, this hasn't been implemented yet.
Rob
Do you need more than CAP_SYS_NICE? CAP_SYS_NICE gives you: * Allow raising priority and setting priority on other (different UID) processes * Allow use of FIFO and round-robin (realtime) scheduling on own processes and setting the scheduling algorithm used by another process. wineserver would need to be a setuid program but it could set CAP_SYS_NICE at startup and immediately reduce it's privileges back to normal.
Robert Reif wrote:
Robert Shearman wrote:
Robert Reif wrote:
Are there any plans or is anyone working on mapping Windows SetProcessClass and SetThreadPriority support to linux process priorities on kernels that support CAP_SYS_NICE?
Mapping Win32 thread priority levels to Linux nice levels is fairly trivial, but convincing kernel developers to allow unprivileged user-space programs to control thread priorities is the big problem. The last time a discussion like this came up, we (Wine developers and Cedega developers) requested a way of changing a thread's relative priority within a process (without affecting the overall CPU time the process gets). This should be a good compromise between meeting applications' needs and preventing unprivileged applications from freezing the computer. AFAIK, this hasn't been implemented yet.
wineserver would need to be a setuid program but it could set CAP_SYS_NICE at startup and immediately reduce it's privileges back to normal.
There are a number of problems: 1. I don't think that will work yet as the server process needs to have the same user ID as the client processes. 2. setuid binaries make sysadmins nervous and would require a security audit by us. Yes, they don't need to make it setuid, but then the people who do could run their programs as root anyway. 3. setuid programs are a nasty hack that work around limitation in the granularity of security in the kernel. 4. This approach won't generalize for other apps on the system that might want to control the relative priority of their threads, such as MPlayer. Rob
On Fri, 08 Apr 2005 13:29:56 -0500, Robert Shearman wrote:
wineserver would need to be a setuid program but it could set CAP_SYS_NICE at startup and immediately reduce it's privileges back to normal.
There are a number of problems: 1. I don't think that will work yet as the server process needs to have the same user ID as the client processes.
You can distinguish between the "user id" and "effective user id" in POSIX. I don't remember the details but a suid binary can almost be two users at once.
2. setuid binaries make sysadmins nervous and would require a security audit by us. Yes, they don't need to make it setuid, but then the people who do could run their programs as root anyway.
Presumably only the code up until the point at which we drop privs needs to be audited though. Suid root binaries that drop privs are pretty common.
3. setuid programs are a nasty hack that work around limitation in the granularity of security in the kernel.
We could use SELinux to achieve the same effect, but it's less widely deployed and understood.
4. This approach won't generalize for other apps on the system that might want to control the relative priority of their threads, such as MPlayer.
*shrug* That's what SELinux is for. Why do we care about MPlayer in this specific instance? thanks -mike
Mike Hearn wrote:
On Fri, 08 Apr 2005 13:29:56 -0500, Robert Shearman wrote:
2. setuid binaries make sysadmins nervous and would require a security audit by us. Yes, they don't need to make it setuid, but then the people who do could run their programs as root anyway.
Presumably only the code up until the point at which we drop privs needs to be audited though. Suid root binaries that drop privs are pretty common.
You're forgetting the reason why we need the suid root binary - because allowing processes to set their priority as realtime (or otherwise very high) leaves the system open to a trvial DoS attack. Not only do the startup code paths need to be audited, but also the priority setting logic too. Rob
On Sun, 2005-04-10 at 19:42 -0500, Robert Shearman wrote:
You're forgetting the reason why we need the suid root binary - because allowing processes to set their priority as realtime (or otherwise very high) leaves the system open to a trvial DoS attack. Not only do the startup code paths need to be audited, but also the priority setting logic too.
Good point. But I don't think there's any way to avoid this: fundamentally anyone can write a Win32 app that requests realtime priority and then goes into an infinite loop. In order to emulate that faithfully Linux just has to budge. It's not like it's hard to DoS a desktop Linux box anyway. Just compile winetest on it ;) <duck>
Hi, On Mon, Apr 11, 2005 at 02:07:47PM +0100, Mike Hearn wrote:
On Sun, 2005-04-10 at 19:42 -0500, Robert Shearman wrote:
You're forgetting the reason why we need the suid root binary - because allowing processes to set their priority as realtime (or otherwise very high) leaves the system open to a trvial DoS attack. Not only do the startup code paths need to be audited, but also the priority setting logic too.
Good point. But I don't think there's any way to avoid this: fundamentally anyone can write a Win32 app that requests realtime priority and then goes into an infinite loop. In order to emulate that faithfully Linux just has to budge. Nope, that's just the main issue of what the CK kernel discussed: how to implement some sort of "realtime" priority *without* DoS capabilities. And the result was SCHED_ISO.
See http://bhhdoa.org.au/pipermail/ck/2004-October/001169.html for an overview. But OTOH your point is still valid: even a SCHED_ISO wouldn't emulate this kind of realtime priority correctly, since it *can* be preempted, which would probably violate Win32 realtime prio properties. Still, it's a very acceptable compromise, I'd say.
It's not like it's hard to DoS a desktop Linux box anyway. Just compile winetest on it ;) <duck> Now that's true ;)
Andreas
participants (5)
-
Andreas Mohr -
Mike Hearn -
Robert Reif -
Robert Shearman -
Troy Rollo