linux-kernel - Re: Where is RLIMIT_RT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 16 Jul 2006 20:14:24 +1000
From:	Jean-Marc Valin <Jean-Marc.Valin@...erbrooke.ca>
To:	Esben Nielsen <nielsen.esben@...glemail.com>
Cc:	Lee Revell <rlrevell@...-job.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: Where is RLIMIT_RT_CPU?

> You can't have "random" users scheduling thing at real-time priorities.
> A real-time system can only work if it is set up as whole and all 
> real-time tasks are taken into consideration. If you allow a user to start 
> another real-time task, that task might destroy the real-time properties 
> of all the rest by taking too much cpu.
> 
> As I see it the only thing you can do is to use sudo to run anything,
> which needs real-time priority, with higher priviliges, than what a normal 
> user have. Then he can only start specific audio programs and can't crash 
> the system (unless those programs have a bug).

I though we were past that point a long time ago. Of course you don't
want *any* random user to have access to rt scheduling. However, you
*do* want the user logged-in on the console be allowed to run tasks with
rt priority (within some limits). Why? Because 1) you don't want to give
root access to any user who needs RT for some apps and 2) you don't want
to make all these apps suid root either. 

Think about it, would you really feel safe with your sound daemon,
Ekiga/Gnomemeeting, jackd, Amarok, mplayer, ... all being run setuid
root. Yet all these apps (and many others) can benefit from being
allowed a few percent CPU running at rt priority. Not to mention the
fact that you may actually want to do rt *development* as a regular
user. That's why people have come up with realtime-lsm, and more
recently, with SCHED_ISO and rt-limit. What's currently missing is just
the tiny bit that prevents the user from locking up the machine. Even
that one was done by Ingo, but unfortunately not merged in the mainline
kernel. Controlled properly, access to rt scheduling is no more
dangerous (and probably less) than fork(), malloc() or mlock(), all of
which can lock up a machine efficiently if unlimited use is allowed.

	Jean-Marc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/