Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263461AbVBCVjD (ORCPT ); Thu, 3 Feb 2005 16:39:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263248AbVBCVhj (ORCPT ); Thu, 3 Feb 2005 16:37:39 -0500 Received: from mx2.elte.hu ([157.181.151.9]:48850 "EHLO mx2.elte.hu") by vger.kernel.org with ESMTP id S261574AbVBCVhJ (ORCPT ); Thu, 3 Feb 2005 16:37:09 -0500 Date: Thu, 3 Feb 2005 22:36:45 +0100 From: Ingo Molnar To: Paul Davis Cc: Peter Williams , "Bill Huey (hui)" , "Jack O'Quin" , Nick Piggin , Con Kolivas , linux , rlrevell@joe-job.com, CK Kernel , utz , Andrew Morton , alexn@dsv.su.se, Rui Nuno Capela , Chris Wright , Arjan van de Ven Subject: Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature Message-ID: <20050203213645.GB27255@elte.hu> References: <42014C10.60407@bigpond.net.au> <200502022303.j12N3nZa002055@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502022303.j12N3nZa002055@localhost.localdomain> User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1335 Lines: 32 * Paul Davis wrote: > Just a reminder: setuid root is precisely what we are attempting to > avoid. > > >If you have the source code for the programs then they could be modified > >to drop the root euid after they've changed policy. Or even do the > > This is insufficient, since they need to be able to drop RT scheduling > and then reacquire it again later. i believe RT-LSM provides a way to solve this cleanly: you can make your audio app setguid-audio (note: NOT setuid), and make the audio group have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you could have a finegrained per-app way of enabling SCHED_FIFO scheduling, without giving _users_ the blanket permission to SCHED_FIFO. Ok? this way if jackd (or a client) gets run by _any_ user, all jackd processes will be part of the audio group and can do SCHED_FIFO - but users are not automatically trusted with SCHED_FIFO. you are currently using RT-LSM to enable a user to do SCHED_FIFO, right? I think the above mechanism is more secure and more finegrained than that. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/