From: Lee Revell <rlrevell@joe-job.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Paul Davis <paul@linuxaudiosystems.com>,
Ingo Molnar <mingo@elte.hu>,
Peter Williams <pwil3058@bigpond.net.au>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Chris Wright <chrisw@osdl.org>,
"Jack O'Quin" <jack.oquin@gmail.com>,
Andrew Morton <akpm@osdl.org>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, Con Kolivas <kernel@kolivas.org>
Subject: Re: 2.6.11-rc3-mm2
Date: Fri, 11 Feb 2005 14:57:21 -0500 [thread overview]
Message-ID: <1108151842.20365.22.camel@krustophenia.net> (raw)
In-Reply-To: <20050211194233.GL15058@waste.org>
On Fri, 2005-02-11 at 11:42 -0800, Matt Mackall wrote:
> On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
> > >RT-LSM introduces architectural problems in the form of bogus API. And
> >
> > that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
> > introduce *any* API whatsoever - it simply allows software to call
> > various existing APIs (mostly from POSIX) and have them not fail as
> > result of not being root and/or not running on a capabilities-enabled
> > kernel without the required caps.
>
> The API is the parameters to modprobe or sysfs.
>
I think you are talking about the API for root to administer it vs. the
(lack of) API for apps to use the RT capabilities. I think Paul's point
is that we can transparently replace it with something better (IMO the
RT rlimit is better) in the future, and the apps don't have to know
about it at all. Comparing it to devfs/udev is bogus because those are
way, way more complicated.
> > >it's implemented as an LSM is meaningless if Redhat and SuSE ship it
> > >on by default.
> >
> > We haven't encouraged anyone to ship anything with it on by default:
> > the idea is for the module to be present and usable, not turned on.
>
> On as in turned on for build in the kernel config and shipped. But I
> expect people will eventually actually ship it _on_ with a group
> called 'rt' and possibly even put the primary user in there on install
> unless you start slapping some big fat warnings on it. (I just noticed
> the new Debian installer is putting the primary user in audio, cdrom,
> video, etc.)
>
Sorry, if the distros are so dumb they need a big fat warning to know
that this is not a safe thing to enable by default, at least on anything
you would ever consider a multiuser system, then they get what they
deserve. If they have half a brain they will use the setgid approach
that Ingo suggested, and only enable this for apps like JACK and
cdrecord that have been farily well audited and can be trusted to use
this feature (for example JACK has the internal watchdog to keep a bad
client from locking the system). Really it only makes sense for a
distro to enable this if the user selects the "low latency desktop" or
"multimedia desktop" or whatever install option and makes clear that
this profile is NOT suitable for a multiuser system.
Lee
next prev parent reply other threads:[~2005-02-11 19:58 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-10 20:51 2.6.11-rc3-mm2 Jack O'Quin
2005-02-11 0:04 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 0:47 ` 2.6.11-rc3-mm2 Chris Wright
2005-02-11 2:09 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 2:22 ` 2.6.11-rc3-mm2 Nick Piggin
2005-02-11 3:26 ` 2.6.11-rc3-mm2 Peter Williams
2005-02-11 3:41 ` 2.6.11-rc3-mm2 Paul Davis
2005-02-11 5:04 ` 2.6.11-rc3-mm2 Nick Piggin
2005-02-11 6:34 ` 2.6.11-rc3-mm2 Peter Williams
2005-02-11 6:42 ` 2.6.11-rc3-mm2 Nick Piggin
2005-02-11 5:09 ` 2.6.11-rc3-mm2 Peter Williams
2005-02-11 6:57 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 7:54 ` 2.6.11-rc3-mm2 Ingo Molnar
2005-02-11 8:25 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 8:48 ` 2.6.11-rc3-mm2 Ingo Molnar
2005-02-11 8:58 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 9:01 ` 2.6.11-rc3-mm2 Ingo Molnar
2005-02-11 9:04 ` 2.6.11-rc3-mm2 Ingo Molnar
2005-02-11 9:27 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 17:49 ` 2.6.11-rc3-mm2 Paul Davis
2005-02-11 19:42 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 19:57 ` Lee Revell [this message]
2005-02-11 8:14 ` 2.6.11-rc3-mm2 Ingo Molnar
2005-02-11 8:22 ` 2.6.11-rc3-mm2 Christoph Hellwig
2005-02-11 8:41 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 8:59 ` 2.6.11-rc3-mm2 Ingo Molnar
2005-02-11 9:40 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 9:53 ` 2.6.11-rc3-mm2 Ingo Molnar
2005-02-11 17:37 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 17:49 ` 2.6.11-rc3-mm2 Ingo Molnar
2005-02-11 20:10 ` 2.6.11-rc3-mm2 Matt Mackall
2005-02-11 17:45 ` 2.6.11-rc3-mm2 Paul Davis
2005-02-14 5:21 ` 2.6.11-rc3-mm2 Werner Almesberger
-- strict thread matches above, loose matches on Subject: below --
2005-02-10 10:35 2.6.11-rc3-mm2 Andrew Morton
2005-02-10 13:35 ` 2.6.11-rc3-mm2 Christoph Hellwig
2005-02-10 20:01 ` 2.6.11-rc3-mm2 Andrew Morton
2005-02-12 22:43 ` 2.6.11-rc3-mm2 Olaf Dietsche
2005-02-10 22:13 ` 2.6.11-rc3-mm2 Corey Minyard
2005-02-10 22:42 ` 2.6.11-rc3-mm2 Benjamin Herrenschmidt
2005-02-10 23:02 ` 2.6.11-rc3-mm2 Andrew Morton
2005-02-10 23:31 ` 2.6.11-rc3-mm2 Benjamin Herrenschmidt
2005-02-10 23:17 ` 2.6.11-rc3-mm2 Adrian Bunk
2005-02-11 16:29 ` 2.6.11-rc3-mm2 Yuval Tanny
2005-02-12 14:53 ` 2.6.11-rc3-mm2 Henning Rohde
2005-02-14 13:22 ` 2.6.11-rc3-mm2 Stefano Rivoir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1108151842.20365.22.camel@krustophenia.net \
--to=rlrevell@joe-job.com \
--cc=akpm@osdl.org \
--cc=chrisw@osdl.org \
--cc=hch@infradead.org \
--cc=jack.oquin@gmail.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mpm@selenic.com \
--cc=nickpiggin@yahoo.com.au \
--cc=paul@linuxaudiosystems.com \
--cc=pwil3058@bigpond.net.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox