On Mon, 17 Jul 2006, Jean-Marc Valin wrote:
Who said suid root? What about suid realtime or suid audio?
Still, I don't see what you gain by making them setuid $group vs
allowing member(s) of $group to use rt scheduling.
My point is not that they can lock up the machine. My point is that you
just can't add a rt task to a rt system! A rt-system consists of a fixed
set of threads, which in worst case can meet it's deadlines. If you add
just one task you might break the whole system. Only someone with overview
of the whole system can add those tasks.
This issue can also happen if you start 10 suid rt apps. It's the
responsibility of the user to make sure there's no bad interaction. The
reason we want a limit is to make sure the system remains relatively
responsive (not just up). In the ideal case (not sure it's possible),
the scheduler would make sure that non-root rt apps wouldn't get (on
average) more CPU than they would get running at normal priority. i.e.
if there are 3 tasks competing and you start a rt task, then that task
couldn't get more than 25% CPU. Of course, it may not be possible to do
that perfectly, but anything remotely close would be pretty good.
In any case, most audio (and probably other) applications tend to only
require a very small amount (<10%) of CPU to run properly. I'd be quite
happy is my system was configured to allow me to run rt tasks as long as
the total doesn't exceed 30% CPU.
It is very simple if you have only a audio application or only a driver
needing low latencies. What if you have both? You have to make sure that
the higher priority one leaves enough cpu for the lower priority one. And
it is not a question of using a low percentage of cpu. It is a question of
how long the cpu is used in one go and how often it can happen within the
critical timeframe of the lower priority application.
I understand that, but adding artificial restrictions (to setuid audio
apps) isn't going to help.
You can make a system which checks that but it is much harder to do than
a moving average. The only thing which makes sense is (a) square filter(s)
with a width equal to the required latency of the lower priority task(s).
Why not? It could be nice as well if someone wants to implement that.
I'd already be quite happy to just have basic control on the CPU time.
So the sys-admin should somehow be able to give the right either to
specific (audio) applications with specific priorities or a developer whom
he trusts (and it does not make sense to give it to both as they would
then mess it up for each other!)
How about simply giving rt rights to whomever is logged on the console?
That's the user that really counts since he's (usually) next to the
audio device.
We have discussed that total lock-up can be prevented with a simple
watchdog. That solution doesn't need anything added into the scheduler.
As I mentioned earlier, it's not about total lock-up, but having things
run relatively smoothly and (if possible?) even fairly.
Jean-Marc
The more I think about it the more it looks like you want a nice -40 task,
not a real-time task. The basic behaviour you want is a task which can
wake up and get the cpu almost immediately, but if it starts to use too
much CPU it looses that privilige. That is you want moving priorities
just as a normal SCHED_OTHER tasks. The only difference is that you want
it to start further up the scale than usual so it takes much longer before
the scheduler has moved it down to a priority, where it has to compete
with other tasks. Maybe it is already enough to run your audio application
at nice -20 ?
When you are not developing for a specific CPU and/or the your application
isn't the only RT application on the system, you can't use real-time
scheduling anyway, it simply doesn't make much sense. Using a very high
SCHED_OTHER priority would probably work much better. Leave the
RT talk for the controlled embedded applications, where the developers (are
supposed to) know and test the whole system.
I also think that Joe user who is locked into the console should only be able
to start specific applications with extraordinary priorities. That is, it
should not be enough to look at his permissions, but look at the permissions
of the program he wants to run. Therefore a suid system is the right thing to
make.
Esben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
