>What I find offensive is you repeatedly telling me I'm naive, when
>I've actually written a proper RT kernel AND run a music production
>company.
But you are being naive Matt! Nobody claims that OSX is hard-RT, or
even that OS9 is hard-RT, but people are able to Get Work Done on
those systems without jumping through hoops or arguing with kernel
developers. This happens because (a) the OS is enough-RT and (b) the
developers in question accepted the requirements of DAW and sequencer
users as totally legitimate.
As I stated before, we already *have* Linux kernels whose performance
in the RT area is at least as good as OSX (thanks to Andrew and Ingo,
primarily), but users cannot access these facilities without doing a
song and dance and a download or two. This is the issue that requires
fixing, from our perspective.
--p
On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
>
> So I still have the rt-lsm patch floating about, saying "merge me, merge
> me!". I'm not sure that the world would end were I to do so.
>
> Consider this a prod in the direction of those who were pushing
> alternatives ;)
It's still a really bad idea. You let the magic gid for oracle hugetlb
patch go in with that reasonsing, now ew have relatime-lsm, next we
$CAPABILITY for $FOO and we're headed straight to interface-hell.
So I still have the rt-lsm patch floating about, saying "merge me, merge
me!". I'm not sure that the world would end were I to do so.
Consider this a prod in the direction of those who were pushing
alternatives ;)
Christoph Hellwig <[email protected]> wrote:
>
> On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> >
> > So I still have the rt-lsm patch floating about, saying "merge me, merge
> > me!". I'm not sure that the world would end were I to do so.
> >
> > Consider this a prod in the direction of those who were pushing
> > alternatives ;)
>
> It's still a really bad idea.
It solves a real problem and is well encapsulated. The world won't end if
we merge it.
Still. My point is: we're still awaiting anything better and thei is just
hanging around and hanging around.
> You let the magic gid for oracle hugetlb
> patch go in with that reasonsing
Which continues to cause zero problems.
> now ew have relatime-lsm,
Not yet.
> next we
> $CAPABILITY for $FOO and we're headed straight to interface-hell.
"interface hell"? Wow.
Still. It seems to be what we deserve if all that fancy stuff we have
cannot address this very simple and very real-world problem.
* Andrew Morton <[email protected]> wrote:
> > next we
> > $CAPABILITY for $FOO and we're headed straight to interface-hell.
>
> "interface hell"? Wow.
>
> Still. It seems to be what we deserve if all that fancy stuff we have
> cannot address this very simple and very real-world problem.
please describe this "very simple and very real-world problem" in simple
terms. Lets make sure "problem" and "solution" didnt become detached.
Ingo
Ingo Molnar <[email protected]> wrote:
>
>
> * Andrew Morton <[email protected]> wrote:
>
> > > next we
> > > $CAPABILITY for $FOO and we're headed straight to interface-hell.
> >
> > "interface hell"? Wow.
> >
> > Still. It seems to be what we deserve if all that fancy stuff we have
> > cannot address this very simple and very real-world problem.
>
> please describe this "very simple and very real-world problem" in simple
> terms. Lets make sure "problem" and "solution" didnt become detached.
>
Well others can do that better than I but I'd describe it as
- Audio apps need to meet their realtime requirements
- The way to implement that is to give them !SCHED_OTHER and mlockall
capabilities.
- But they don't want to run as root.
On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote:
> > please describe this "very simple and very real-world problem" in simple
> > terms. Lets make sure "problem" and "solution" didnt become detached.
> >
>
> Well others can do that better than I but I'd describe it as
>
> - Audio apps need to meet their realtime requirements
>
> - The way to implement that is to give them !SCHED_OTHER and mlockall
> capabilities.
>
> - But they don't want to run as root.
Which all fits very nicely with MEMLOCK rlimit and a tiny wrapper
that sets !SCHED_OTHER and execs the audio app..
and as I mentioned a few times if we really want to go for a magic
uid/gid-based approach we should at least have one that's useable for
all capabilities so it can replace the oracle hack aswell. But the
proponents of the patch weren't iterested to invest the tiniest bit
of work over what they submited.
On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
>
> So I still have the rt-lsm patch floating about, saying "merge me, merge
> me!". I'm not sure that the world would end were I to do so.
>
> Consider this a prod in the direction of those who were pushing
> alternatives ;)
I think Chris Wright's last rlimit patch is more sensible and ready to
go. And I think I may have even convinced Ingo on this point before
the conversation died last time around. So here's that patch again,
updated to 2.6.11. Compiles cleanly. Chris, please add a signed-off-by.
<snip>
Add a pair of rlimits for allowing non-root tasks to raise nice and rt
priorities. Defaults to traditional behavior. Originally written by
Chris Wright.
Signed-off-by: Matt Mackall <[email protected]>
Index: rlimits/include/linux/sched.h
===================================================================
--- rlimits.orig/include/linux/sched.h 2005-03-03 22:50:14.000000000 -0800
+++ rlimits/include/linux/sched.h 2005-03-07 20:18:30.000000000 -0800
@@ -791,6 +791,7 @@ extern void sched_idle_next(void);
extern void set_user_nice(task_t *p, long nice);
extern int task_prio(const task_t *p);
extern int task_nice(const task_t *p);
+extern int can_nice(const task_t *p, const int nice);
extern int task_curr(const task_t *p);
extern int idle_cpu(int cpu);
extern int sched_setscheduler(struct task_struct *, int, struct sched_param *);
Index: rlimits/kernel/sched.c
===================================================================
--- rlimits.orig/kernel/sched.c 2005-03-02 22:51:08.000000000 -0800
+++ rlimits/kernel/sched.c 2005-03-07 20:23:17.000000000 -0800
@@ -3273,6 +3273,19 @@ out_unlock:
EXPORT_SYMBOL(set_user_nice);
+/*
+ * can_nice - check if a task can reduce its nice value
+ * @p: task
+ * @nice: nice value
+ */
+int can_nice(const task_t *p, const int nice)
+{
+ /* convert nice value [19,-20] to rlimit style value [0,39] */
+ int nice_rlim = 19 - nice;
+ return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
+ capable(CAP_SYS_NICE));
+}
+
#ifdef __ARCH_WANT_SYS_NICE
/*
@@ -3292,12 +3305,8 @@ asmlinkage long sys_nice(int increment)
* We don't have to worry. Conceptually one call occurs first
* and we have a single winner.
*/
- if (increment < 0) {
- if (!capable(CAP_SYS_NICE))
- return -EPERM;
- if (increment < -40)
- increment = -40;
- }
+ if (increment < -40)
+ increment = -40;
if (increment > 40)
increment = 40;
@@ -3307,6 +3316,9 @@ asmlinkage long sys_nice(int increment)
if (nice > 19)
nice = 19;
+ if (increment < 0 && !can_nice(current, nice))
+ return -EPERM;
+
retval = security_task_setnice(current, nice);
if (retval)
return retval;
@@ -3422,6 +3434,7 @@ recheck:
return -EINVAL;
if ((policy == SCHED_FIFO || policy == SCHED_RR) &&
+ param->sched_priority > p->signal->rlim[RLIMIT_RTPRIO].rlim_cur &&
!capable(CAP_SYS_NICE))
return -EPERM;
if ((current->euid != p->euid) && (current->euid != p->uid) &&
Index: rlimits/kernel/sys.c
===================================================================
--- rlimits.orig/kernel/sys.c 2005-03-02 22:51:07.000000000 -0800
+++ rlimits/kernel/sys.c 2005-03-07 20:18:30.000000000 -0800
@@ -225,7 +225,7 @@ static int set_one_prio(struct task_stru
error = -EPERM;
goto out;
}
- if (niceval < task_nice(p) && !capable(CAP_SYS_NICE)) {
+ if (niceval < task_nice(p) && !can_nice(p, niceval)) {
error = -EACCES;
goto out;
}
Index: rlimits/include/asm-generic/resource.h
===================================================================
--- rlimits.orig/include/asm-generic/resource.h 2005-03-02 18:30:27.000000000 -0800
+++ rlimits/include/asm-generic/resource.h 2005-03-07 20:21:04.000000000 -0800
@@ -20,8 +20,10 @@
#define RLIMIT_LOCKS 10 /* maximum file locks held */
#define RLIMIT_SIGPENDING 11 /* max number of pending signals */
#define RLIMIT_MSGQUEUE 12 /* maximum bytes in POSIX mqueues */
-
-#define RLIM_NLIMITS 13
+#define RLIMIT_NICE 13 /* max nice prio allowed to raise to
+ 0-39 for nice level 19 .. -20 */
+#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
+#define RLIM_NLIMITS 15
#endif
/*
@@ -53,6 +55,8 @@
[RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
[RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
[RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
+ [RLIMIT_NICE] = { 0, 0 }, \
+ [RLIMIT_RTPRIO] = { 0, 0 }, \
}
#endif /* __KERNEL__ */
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall <[email protected]> wrote:
>
> I think Chris Wright's last rlimit patch is more sensible and ready to
> go.
I must say that I like rlimits - very straightforward, although somewhat
awkward to use from userspace due to shortsighted shell design.
Does anyone have serious objections to this approach?
On Tue, Mar 08, 2005 at 04:32:50AM +0000, Christoph Hellwig wrote:
> On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote:
> > > please describe this "very simple and very real-world problem" in simple
> > > terms. Lets make sure "problem" and "solution" didnt become detached.
> > >
> >
> > Well others can do that better than I but I'd describe it as
> >
> > - Audio apps need to meet their realtime requirements
Add video, data acquisition, motion control, CD burning, etc..
> > - The way to implement that is to give them !SCHED_OTHER and mlockall
> > capabilities.
> >
> > - But they don't want to run as root.
>
> Which all fits very nicely with MEMLOCK rlimit and a tiny wrapper
> that sets !SCHED_OTHER and execs the audio app..
This is somewhat complicated by the fact that the existing apps are
already running and instead need promotion. Then we run into problems
lie set_rlimit doesn't want to work on other processes and issues with
sched_setparam on other threads, etc.
Part of me wants to say, well you designed it wrong. You should have
planned a setuid launcher for the rt threads. But at the same time,
the rlimits thing seems like a reasonably clean way to give RT access
to users, and still allows for protect watchdog processes..
> and as I mentioned a few times if we really want to go for a magic
> uid/gid-based approach we should at least have one that's useable for
> all capabilities so it can replace the oracle hack aswell. But the
> proponents of the patch weren't iterested to invest the tiniest bit
> of work over what they submited.
Does the mlock rlimit not already address the Oracle problem?
--
Mathematics is the supreme nostalgia of our time.
* Matt Mackall ([email protected]) wrote:
> On Tue, Mar 08, 2005 at 04:32:50AM +0000, Christoph Hellwig wrote:
> > On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote:
> > > > please describe this "very simple and very real-world problem" in simple
> > > > terms. Lets make sure "problem" and "solution" didnt become detached.
> > > >
> > >
> > > Well others can do that better than I but I'd describe it as
> > >
> > > - Audio apps need to meet their realtime requirements
>
> Add video, data acquisition, motion control, CD burning, etc..
>
> > > - The way to implement that is to give them !SCHED_OTHER and mlockall
> > > capabilities.
> > >
> > > - But they don't want to run as root.
> >
> > Which all fits very nicely with MEMLOCK rlimit and a tiny wrapper
> > that sets !SCHED_OTHER and execs the audio app..
>
> This is somewhat complicated by the fact that the existing apps are
> already running and instead need promotion. Then we run into problems
> lie set_rlimit doesn't want to work on other processes and issues with
> sched_setparam on other threads, etc.
>
> Part of me wants to say, well you designed it wrong. You should have
> planned a setuid launcher for the rt threads. But at the same time,
> the rlimits thing seems like a reasonably clean way to give RT access
> to users, and still allows for protect watchdog processes..
>
> > and as I mentioned a few times if we really want to go for a magic
> > uid/gid-based approach we should at least have one that's useable for
> > all capabilities so it can replace the oracle hack aswell. But the
> > proponents of the patch weren't iterested to invest the tiniest bit
> > of work over what they submited.
>
> Does the mlock rlimit not already address the Oracle problem?
It does, that's effectively dead code as far as I'm concerned. The mlock
bit just came in a bit later. I had a patch around here to rip it out,
this should be a good time to dust that off.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
> * Andrew Morton <[email protected]> wrote:
>
>> Still. It seems to be what we deserve if all that fancy stuff we have
>> cannot address this very simple and very real-world problem.
Ingo Molnar <[email protected]> writes:
> please describe this "very simple and very real-world problem" in simple
> terms. Lets make sure "problem" and "solution" didnt become detached.
Linux audio users need to run large, complex low-latency desktop audio
applications without granting them full root privileges. These
applications require reliable SCHED_FIFO (or equivalent) scheduling,
and the ability to lock process images into memory. We need to be
able to drop and reacquire these privileges from time to time. We
strongly prefer using the POSIX realtime interfaces.
For desktop musicians this needs to be simple to administer, yet still
reasonably secure. Denial of service attacks are not a serious threat
in our environment, but we really don't want people turning our
systems into open spam relays or creating hidden setuid root shells.
Ours is *not* a timesharing multiuser environment. Multiple users may
access these systems, but only one at a time. Many musicians have a
Mac or Windows background, systems which grant realtime privileges to
all tasks indiscriminantly. The realtime LSM allows us to grant
similar privileges while maintaining better control over who gets
them, a significant improvement over our competition.
AFAICT, video and probably some other desktop multimedia applications
have similar needs, but others should speak for them. I do know that
audio is highly sensitive to realtime performance glitches.
We believe that this LSM meets our needs, because hundreds of us have
used it successfully for over a year. This is the last missing piece
that allows us to reap the benefits of the excellent kernel latency
improvements Ingo, Andrew and others have made over the last several
years.
--
joq
Andrew Morton <[email protected]> writes:
> Matt Mackall <[email protected]> wrote:
>>
>> I think Chris Wright's last rlimit patch is more sensible and ready to
>> go.
>
> I must say that I like rlimits - very straightforward, although somewhat
> awkward to use from userspace due to shortsighted shell design.
>
> Does anyone have serious objections to this approach?
1. is likely to introduce multiuser system security holes like the one
created recently when the mlock() rlimits bug was fixed (DoS attacks)
2. requires updates to all the shells
3. forces Windows and Mac musicians to learn and understand PAM
4. is undocumented and has never been tested in any real music studios
--
joq
* Matt Mackall <[email protected]> wrote:
> Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> priorities. Defaults to traditional behavior. Originally written by
> Chris Wright.
>
> Signed-off-by: Matt Mackall <[email protected]>
this too looks good to me.
Acked-by: Ingo Molnar <[email protected]>
(no strong feelings either way, other than rlimits feel a bit less
hackish.)
Ingo
Andrew Morton wrote:
> Matt Mackall <[email protected]> wrote:
>
>>I think Chris Wright's last rlimit patch is more sensible and ready to
>> go.
>
>
> I must say that I like rlimits - very straightforward, although somewhat
> awkward to use from userspace due to shortsighted shell design.
>
> Does anyone have serious objections to this approach?
I don't object to rlimits per se and I think that they are useful but
not as a sole solution to this problem. Being able to give a task
preferential treatment is a permissions issue and should be solved as one.
Having RT cpu usage limits on tasks is a useful tool to have when
granting normal users the privilege of running tasks as RT tasks so that
you can limit the damage that they can do BUT the presence of a limit on
a task is not a very good criterion for granting that privilege.
The granting of the ability to switch to and from RT mode should require
a means to specify which users it applies to and also which programs it
applies to. The RT rlimits mechanism doesn't meet these criteria.
In summary, IMHO you should put them both in but modify the RT rlimits
patch so that it plays no part in the decision as to whether the task is
allowed to run as RT or not.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
* Peter Williams <[email protected]> wrote:
> I don't object to rlimits per se and I think that they are useful but
> not as a sole solution to this problem. Being able to give a task
> preferential treatment is a permissions issue and should be solved as
> one.
>
> Having RT cpu usage limits on tasks is a useful tool to have when
> granting normal users the privilege of running tasks as RT tasks so
> that you can limit the damage that they can do BUT the presence of a
> limit on a task is not a very good criterion for granting that
> privilege.
i think you are talking about my rlimit patch (the 'RT CPU limit' patch)
- but that one is not in discussion here.
what is being discussed currently is the other rlimit patch (from Chris
Wright and Matt Mackall) which implements a simple rlimit ceiling for
the RT (and nice) priorities a task can set. The rlimit defaults to 0,
meaning no change in behavior by default. A value of 50 means RT
priority levels 1-50 are allowed. A value of 100 means all 99 privilege
levels from 1 to 99 are allowed. CAP_SYS_NICE is blanket permission.
It's all pretty finegrained and and it's a quite straightforward
extension of what we have today. The patch does not attempt to do any
"damage control" of abuse caused by RT tasks, and is hence much simpler
than my patch or Con's SCHED_ISO patch. ("damage control" could be done
from userspace anyway)
Ingo
* Peter Williams ([email protected]) wrote:
> Andrew Morton wrote:
> >Matt Mackall <[email protected]> wrote:
> >
> >>I think Chris Wright's last rlimit patch is more sensible and ready to
> >>go.
> >
> >
> >I must say that I like rlimits - very straightforward, although somewhat
> >awkward to use from userspace due to shortsighted shell design.
> >
> >Does anyone have serious objections to this approach?
>
> I don't object to rlimits per se and I think that they are useful but
> not as a sole solution to this problem. Being able to give a task
> preferential treatment is a permissions issue and should be solved as one.
>
> Having RT cpu usage limits on tasks is a useful tool to have when
> granting normal users the privilege of running tasks as RT tasks so that
> you can limit the damage that they can do BUT the presence of a limit on
> a task is not a very good criterion for granting that privilege.
>
> The granting of the ability to switch to and from RT mode should require
> a means to specify which users it applies to and also which programs it
> applies to. The RT rlimits mechanism doesn't meet these criteria.
>
> In summary, IMHO you should put them both in but modify the RT rlimits
> patch so that it plays no part in the decision as to whether the task is
> allowed to run as RT or not.
I'm not sure I follow you. This patch just sets the max RT priority a
process can have (defaults to 0, as w/out the patch). Increasing that
value is a form of permission granting, giving the process the ability
to increase its RT prio if it chooses to ask for it.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Tue, Mar 08, 2005 at 04:40:02PM +1100, Peter Williams wrote:
> The granting of the ability to switch to and from RT mode should require
> a means to specify which users it applies to and also which programs it
> applies to. The RT rlimits mechanism doesn't meet these criteria.
a) rlimits are per-process
b) rlimits are typically administered per-user
c) any user can trivially gain any privilege of any process they own
so in some sense per-process limits are meaningless
So rlimits are in fact as granular as can be, both in theory and in
practice.
--
Mathematics is the supreme nostalgia of our time.
Ingo Molnar wrote:
> * Peter Williams <[email protected]> wrote:
>
>
>>I don't object to rlimits per se and I think that they are useful but
>>not as a sole solution to this problem. Being able to give a task
>>preferential treatment is a permissions issue and should be solved as
>>one.
>>
>>Having RT cpu usage limits on tasks is a useful tool to have when
>>granting normal users the privilege of running tasks as RT tasks so
>>that you can limit the damage that they can do BUT the presence of a
>>limit on a task is not a very good criterion for granting that
>>privilege.
>
>
> i think you are talking about my rlimit patch (the 'RT CPU limit' patch)
> - but that one is not in discussion here.
>
> what is being discussed currently is the other rlimit patch (from Chris
> Wright and Matt Mackall) which implements a simple rlimit ceiling for
> the RT (and nice) priorities a task can set. The rlimit defaults to 0,
> meaning no change in behavior by default. A value of 50 means RT
> priority levels 1-50 are allowed. A value of 100 means all 99 privilege
> levels from 1 to 99 are allowed. CAP_SYS_NICE is blanket permission.
> It's all pretty finegrained and and it's a quite straightforward
> extension of what we have today.
OK. My misunderstanding.
But the patch you describe still seems a little loose to me in that it
doesn't control both which users AND which programs they can run.
Although I suppose that can be managed by suitable setting of file
permissions?
Also I presume that root privileges are needed to set the rlimits which
means that the program has to be setuid root or run from a setuid root
wrapper. In the first of these cases the program will be running for a
(hopefully) short while with way more privilege than it needs. This is
why I'm attracted to mechanisms that allow programs to be given a subset
of root's privileges and only for specified users.
I would be nice to have a solution to this particular problem that fits
in with such a generalized "granular" privilege mechanism (when/if such
a mechanism becomes available in the future) rather than a quirky fix
that is specific to this problem and doesn't generalize well to similar
problems when they arise in the future. However, I agree with your
opinion that granting CAP_SYS_NICE is dangerous without some limit on
the priority levels is dangerous and think that a generalized "granular"
privilege mechanism would need to include such restrictions.
> The patch does not attempt to do any
> "damage control" of abuse caused by RT tasks, and is hence much simpler
> than my patch or Con's SCHED_ISO patch. ("damage control" could be done
> from userspace anyway)
Yes. In kernel "damage control" is an optional extra not a necessity
with this solution. Not so sure about with the RT LSB solution though.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote:
> Andrew Morton <[email protected]> writes:
>
> > Matt Mackall <[email protected]> wrote:
> >>
> >> I think Chris Wright's last rlimit patch is more sensible and ready to
> >> go.
> >
> > I must say that I like rlimits - very straightforward, although somewhat
> > awkward to use from userspace due to shortsighted shell design.
> >
> > Does anyone have serious objections to this approach?
>
> 1. is likely to introduce multiuser system security holes like the one
> created recently when the mlock() rlimits bug was fixed (DoS attacks)
I wouldn't say "likely". But anything's possible, so I wouldn't rule
it out entirely.
> 2. requires updates to all the shells
Requires update to the PAM distro for our purposes.
> 3. forces Windows and Mac musicians to learn and understand PAM
Or for the distro (ubuntu or whatever) to catch up. The alternative is
for the user to compile their own kernel module and mess with its
arcane interface.
> 4. is undocumented and has never been tested in any real music studios
Well you'll have a bit to test it before it goes to Linus.
--
Mathematics is the supreme nostalgia of our time.
* Peter Williams ([email protected]) wrote:
> But the patch you describe still seems a little loose to me in that it
> doesn't control both which users AND which programs they can run.
> Although I suppose that can be managed by suitable setting of file
> permissions?
rlimits are typically handled per user or per group. this is set during
login and the limits apply to the users session. none of the solutions
limit which programs the user can run, however strictly group based priv
granting can reduce the number of processes with the privs (using setgid
programs).
> Also I presume that root privileges are needed to set the rlimits which
> means that the program has to be setuid root or run from a setuid root
> wrapper. In the first of these cases the program will be running for a
> (hopefully) short while with way more privilege than it needs. This is
> why I'm attracted to mechanisms that allow programs to be given a subset
> of root's privileges and only for specified users.
typically this is handled via pam during login, so yes, root (or more
specifically CAP_SYS_RESOURCE) is required, but need not be in any
wrapper. limiting the allowed programs a user/role/domain/context/etc
can run is the goal of other type of security restrictions (such as
SELinux).
> I would be nice to have a solution to this particular problem that fits
> in with such a generalized "granular" privilege mechanism (when/if such
> a mechanism becomes available in the future) rather than a quirky fix
> that is specific to this problem and doesn't generalize well to similar
> problems when they arise in the future. However, I agree with your
> opinion that granting CAP_SYS_NICE is dangerous without some limit on
> the priority levels is dangerous and think that a generalized "granular"
> privilege mechanism would need to include such restrictions.
>
> >The patch does not attempt to do any
> >"damage control" of abuse caused by RT tasks, and is hence much simpler
> >than my patch or Con's SCHED_ISO patch. ("damage control" could be done
> >from userspace anyway)
>
> Yes. In kernel "damage control" is an optional extra not a necessity
> with this solution. Not so sure about with the RT LSB solution though.
This has one advantage over RT LSM in that area, which is it places an
upper bound on the priority (in control of the admin). So it's possible
to save some space for damage control in the top few prio slots.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
* Chris Wright <[email protected]> wrote:
> > Yes. In kernel "damage control" is an optional extra not a necessity
> > with this solution. Not so sure about with the RT LSB solution though.
>
> This has one advantage over RT LSM in that area, which is it places an
> upper bound on the priority (in control of the admin). So it's
> possible to save some space for damage control in the top few prio
> slots.
it's not just purely for damage control - there have been requests of
being able to 'partition' the RT priorities space between applications.
(It's an afterthought but nice nevertheless.)
Ingo
* Matt Mackall ([email protected]) wrote:
> On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> > Consider this a prod in the direction of those who were pushing
> > alternatives ;)
>
> I think Chris Wright's last rlimit patch is more sensible and ready to
> go. And I think I may have even convinced Ingo on this point before
> the conversation died last time around. So here's that patch again,
> updated to 2.6.11. Compiles cleanly. Chris, please add a signed-off-by.
Only very minor nits below.
> Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> priorities. Defaults to traditional behavior. Originally written by
> Chris Wright.
>
> Signed-off-by: Matt Mackall <[email protected]>
>
> Index: rlimits/include/asm-generic/resource.h
> ===================================================================
> --- rlimits.orig/include/asm-generic/resource.h 2005-03-02 18:30:27.000000000 -0800
> +++ rlimits/include/asm-generic/resource.h 2005-03-07 20:21:04.000000000 -0800
> @@ -20,8 +20,10 @@
> #define RLIMIT_LOCKS 10 /* maximum file locks held */
> #define RLIMIT_SIGPENDING 11 /* max number of pending signals */
> #define RLIMIT_MSGQUEUE 12 /* maximum bytes in POSIX mqueues */
> -
> -#define RLIM_NLIMITS 13
> +#define RLIMIT_NICE 13 /* max nice prio allowed to raise to
> + 0-39 for nice level 19 .. -20 */
> +#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
Needs one more tab to keep in line with rest.
> +#define RLIM_NLIMITS 15
> #endif
>
> /*
> @@ -53,6 +55,8 @@
> [RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
> [RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
> [RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
> + [RLIMIT_NICE] = { 0, 0 }, \
> + [RLIMIT_RTPRIO] = { 0, 0 }, \
Might as well fit in with rest of file on these too.
Also, missed alpha, sparc, sparc64, and mips. BTW, where's that last
cleanup from Ingo to consolidate these? Ah, just saw these are inflight
to Linus' tree, nevermind.
Below fixes those nits, and rediffs against that inflight cleanup so it
should apply cleanly on top of that.
thanks,
-chris
--
Add a pair of rlimits for allowing non-root tasks to raise nice and rt
priorities. Defaults to traditional behavior. Originally written by
Chris Wright.
Signed-off-by: Matt Mackall <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
===== include/asm-generic/resource.h 1.1 vs edited =====
--- 1.1/include/asm-generic/resource.h 2005-01-20 21:00:51 -08:00
+++ edited/include/asm-generic/resource.h 2005-03-07 21:15:00 -08:00
@@ -41,8 +41,10 @@
#define RLIMIT_LOCKS 10 /* maximum file locks held */
#define RLIMIT_SIGPENDING 11 /* max number of pending signals */
#define RLIMIT_MSGQUEUE 12 /* maximum bytes in POSIX mqueues */
-
-#define RLIM_NLIMITS 13
+#define RLIMIT_NICE 13 /* max nice prio allowed to raise to
+ 0-39 for nice level 19 .. -20 */
+#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
+#define RLIM_NLIMITS 15
/*
* SuS says limits have to be unsigned.
@@ -81,6 +83,8 @@
[RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
[RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
[RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
+ [RLIMIT_NICE] = { 0, 0 }, \
+ [RLIMIT_RTPRIO] = { 0, 0 }, \
}
#endif /* __KERNEL__ */
===== include/linux/sched.h 1.279 vs edited =====
--- 1.279/include/linux/sched.h 2005-03-04 22:41:13 -08:00
+++ edited/include/linux/sched.h 2005-03-07 21:43:39 -08:00
@@ -792,6 +792,7 @@ extern void sched_idle_next(void);
extern void set_user_nice(task_t *p, long nice);
extern int task_prio(const task_t *p);
extern int task_nice(const task_t *p);
+extern int can_nice(const task_t *p, const int nice);
extern int task_curr(const task_t *p);
extern int idle_cpu(int cpu);
extern int sched_setscheduler(struct task_struct *, int, struct sched_param *);
===== kernel/sched.c 1.394 vs edited =====
--- 1.394/kernel/sched.c 2005-03-04 22:41:14 -08:00
+++ edited/kernel/sched.c 2005-03-07 21:43:39 -08:00
@@ -3278,6 +3278,19 @@ out_unlock:
EXPORT_SYMBOL(set_user_nice);
+/*
+ * can_nice - check if a task can reduce its nice value
+ * @p: task
+ * @nice: nice value
+ */
+int can_nice(const task_t *p, const int nice)
+{
+ /* convert nice value [19,-20] to rlimit style value [0,39] */
+ int nice_rlim = 19 - nice;
+ return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
+ capable(CAP_SYS_NICE));
+}
+
#ifdef __ARCH_WANT_SYS_NICE
/*
@@ -3297,12 +3310,8 @@ asmlinkage long sys_nice(int increment)
* We don't have to worry. Conceptually one call occurs first
* and we have a single winner.
*/
- if (increment < 0) {
- if (!capable(CAP_SYS_NICE))
- return -EPERM;
- if (increment < -40)
- increment = -40;
- }
+ if (increment < -40)
+ increment = -40;
if (increment > 40)
increment = 40;
@@ -3312,6 +3321,9 @@ asmlinkage long sys_nice(int increment)
if (nice > 19)
nice = 19;
+ if (increment < 0 && !can_nice(current, nice))
+ return -EPERM;
+
retval = security_task_setnice(current, nice);
if (retval)
return retval;
@@ -3427,6 +3439,7 @@ recheck:
return -EINVAL;
if ((policy == SCHED_FIFO || policy == SCHED_RR) &&
+ param->sched_priority > p->signal->rlim[RLIMIT_RTPRIO].rlim_cur &&
!capable(CAP_SYS_NICE))
return -EPERM;
if ((current->euid != p->euid) && (current->euid != p->uid) &&
===== kernel/sys.c 1.104 vs edited =====
--- 1.104/kernel/sys.c 2005-01-11 16:42:35 -08:00
+++ edited/kernel/sys.c 2005-03-07 21:10:23 -08:00
@@ -225,7 +225,7 @@ static int set_one_prio(struct task_stru
error = -EPERM;
goto out;
}
- if (niceval < task_nice(p) && !capable(CAP_SYS_NICE)) {
+ if (niceval < task_nice(p) && !can_nice(p, niceval)) {
error = -EACCES;
goto out;
}
On Mon, Mar 07, 2005 at 10:45:05PM -0800, Chris Wright wrote:
> * Matt Mackall ([email protected]) wrote:
> > On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> > > Consider this a prod in the direction of those who were pushing
> > > alternatives ;)
> >
> > I think Chris Wright's last rlimit patch is more sensible and ready to
> > go. And I think I may have even convinced Ingo on this point before
> > the conversation died last time around. So here's that patch again,
> > updated to 2.6.11. Compiles cleanly. Chris, please add a signed-off-by.
>
> Only very minor nits below.
>
> > Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> > priorities. Defaults to traditional behavior. Originally written by
> > Chris Wright.
> >
> > Signed-off-by: Matt Mackall <[email protected]>
> >
> > Index: rlimits/include/asm-generic/resource.h
> > ===================================================================
> > --- rlimits.orig/include/asm-generic/resource.h 2005-03-02 18:30:27.000000000 -0800
> > +++ rlimits/include/asm-generic/resource.h 2005-03-07 20:21:04.000000000 -0800
> > @@ -20,8 +20,10 @@
> > #define RLIMIT_LOCKS 10 /* maximum file locks held */
> > #define RLIMIT_SIGPENDING 11 /* max number of pending signals */
> > #define RLIMIT_MSGQUEUE 12 /* maximum bytes in POSIX mqueues */
> > -
> > -#define RLIM_NLIMITS 13
> > +#define RLIMIT_NICE 13 /* max nice prio allowed to raise to
> > + 0-39 for nice level 19 .. -20 */
> > +#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
>
> Needs one more tab to keep in line with rest.
That's just tab damage from the patch.
> > +#define RLIM_NLIMITS 15
>
>
> > #endif
> >
> > /*
> > @@ -53,6 +55,8 @@
> > [RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
> > [RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
> > [RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
> > + [RLIMIT_NICE] = { 0, 0 }, \
> > + [RLIMIT_RTPRIO] = { 0, 0 }, \
>
> Might as well fit in with rest of file on these too.
>
> Also, missed alpha, sparc, sparc64, and mips. BTW, where's that last
> cleanup from Ingo to consolidate these? Ah, just saw these are inflight
> to Linus' tree, nevermind.
Uhh, is that not what I've already done above?
> -#define RLIM_NLIMITS 13
> +#define RLIMIT_NICE 13 /* max nice prio allowed to raise to
> + 0-39 for nice level 19 .. -20 */
> +#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
Heh.
Anyway...
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall <[email protected]> wrote:
>
> Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> priorities. Defaults to traditional behavior. Originally written by
> Chris Wright.
It needs some dinking with because Ingo has been playing games in my
resource.h. Here's the end result. Unlike yours, this will work on alpha,
mips and sparc[64], too ;)
From: Matt Mackall <[email protected]>
Add a pair of rlimits for allowing non-root tasks to raise nice and rt
priorities. Defaults to traditional behavior. Originally written by
Chris Wright.
The patch implements a simple rlimit ceiling for the RT (and nice) priorities
a task can set. The rlimit defaults to 0, meaning no change in behavior by
default. A value of 50 means RT priority levels 1-50 are allowed. A value of
100 means all 99 privilege levels from 1 to 99 are allowed. CAP_SYS_NICE is
blanket permission.
Signed-off-by: Matt Mackall <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
25-akpm/include/asm-generic/resource.h | 7 ++++++-
25-akpm/include/linux/sched.h | 1 +
25-akpm/kernel/sched.c | 25 +++++++++++++++++++------
25-akpm/kernel/sys.c | 2 +-
4 files changed, 27 insertions(+), 8 deletions(-)
diff -puN include/asm-generic/resource.h~nice-and-rt-prio-rlimits include/asm-generic/resource.h
--- 25/include/asm-generic/resource.h~nice-and-rt-prio-rlimits 2005-03-07 22:50:45.000000000 -0800
+++ 25-akpm/include/asm-generic/resource.h 2005-03-07 22:52:10.000000000 -0800
@@ -41,8 +41,11 @@
#define RLIMIT_LOCKS 10 /* maximum file locks held */
#define RLIMIT_SIGPENDING 11 /* max number of pending signals */
#define RLIMIT_MSGQUEUE 12 /* maximum bytes in POSIX mqueues */
+#define RLIMIT_NICE 13 /* max nice prio allowed to raise to
+ 0-39 for nice level 19 .. -20 */
+#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
-#define RLIM_NLIMITS 13
+#define RLIM_NLIMITS 15
/*
* SuS says limits have to be unsigned.
@@ -81,6 +84,8 @@
[RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
[RLIMIT_SIGPENDING] = { 0, 0 }, \
[RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
+ [RLIMIT_NICE] = { 0, 0 }, \
+ [RLIMIT_RTPRIO] = { 0, 0 }, \
}
#endif /* __KERNEL__ */
diff -puN include/linux/sched.h~nice-and-rt-prio-rlimits include/linux/sched.h
--- 25/include/linux/sched.h~nice-and-rt-prio-rlimits 2005-03-07 22:50:45.000000000 -0800
+++ 25-akpm/include/linux/sched.h 2005-03-07 22:50:45.000000000 -0800
@@ -872,6 +872,7 @@ extern void sched_idle_next(void);
extern void set_user_nice(task_t *p, long nice);
extern int task_prio(const task_t *p);
extern int task_nice(const task_t *p);
+extern int can_nice(const task_t *p, const int nice);
extern int task_curr(const task_t *p);
extern int idle_cpu(int cpu);
extern int sched_setscheduler(struct task_struct *, int, struct sched_param *);
diff -puN kernel/sched.c~nice-and-rt-prio-rlimits kernel/sched.c
--- 25/kernel/sched.c~nice-and-rt-prio-rlimits 2005-03-07 22:50:45.000000000 -0800
+++ 25-akpm/kernel/sched.c 2005-03-07 22:50:45.000000000 -0800
@@ -3304,6 +3304,19 @@ struct task_struct *kgdb_get_idle(int th
}
#endif
+/*
+ * can_nice - check if a task can reduce its nice value
+ * @p: task
+ * @nice: nice value
+ */
+int can_nice(const task_t *p, const int nice)
+{
+ /* convert nice value [19,-20] to rlimit style value [0,39] */
+ int nice_rlim = 19 - nice;
+ return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
+ capable(CAP_SYS_NICE));
+}
+
#ifdef __ARCH_WANT_SYS_NICE
/*
@@ -3323,12 +3336,8 @@ asmlinkage long sys_nice(int increment)
* We don't have to worry. Conceptually one call occurs first
* and we have a single winner.
*/
- if (increment < 0) {
- if (!capable(CAP_SYS_NICE))
- return -EPERM;
- if (increment < -40)
- increment = -40;
- }
+ if (increment < -40)
+ increment = -40;
if (increment > 40)
increment = 40;
@@ -3338,6 +3347,9 @@ asmlinkage long sys_nice(int increment)
if (nice > 19)
nice = 19;
+ if (increment < 0 && !can_nice(current, nice))
+ return -EPERM;
+
retval = security_task_setnice(current, nice);
if (retval)
return retval;
@@ -3453,6 +3465,7 @@ recheck:
return -EINVAL;
if ((policy == SCHED_FIFO || policy == SCHED_RR) &&
+ param->sched_priority > p->signal->rlim[RLIMIT_RTPRIO].rlim_cur &&
!capable(CAP_SYS_NICE))
return -EPERM;
if ((current->euid != p->euid) && (current->euid != p->uid) &&
diff -puN kernel/sys.c~nice-and-rt-prio-rlimits kernel/sys.c
--- 25/kernel/sys.c~nice-and-rt-prio-rlimits 2005-03-07 22:50:45.000000000 -0800
+++ 25-akpm/kernel/sys.c 2005-03-07 22:50:45.000000000 -0800
@@ -229,7 +229,7 @@ static int set_one_prio(struct task_stru
error = -EPERM;
goto out;
}
- if (niceval < task_nice(p) && !capable(CAP_SYS_NICE)) {
+ if (niceval < task_nice(p) && !can_nice(p, niceval)) {
error = -EACCES;
goto out;
}
_
On Mon, Mar 07, 2005 at 10:55:35PM -0800, Andrew Morton wrote:
> Matt Mackall <[email protected]> wrote:
> >
> > Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> > priorities. Defaults to traditional behavior. Originally written by
> > Chris Wright.
>
> It needs some dinking with because Ingo has been playing games in my
> resource.h. Here's the end result. Unlike yours, this will work on alpha,
> mips and sparc[64], too ;)
Boggle. The diffstat of this patch (and Chris') looks identical to
mine. Whatever..
--
Mathematics is the supreme nostalgia of our time.
On Tue, 2005-03-08 at 04:32 +0000, Christoph Hellwig wrote:
> and as I mentioned a few times if we really want to go for a magic
> uid/gid-based approach we should at least have one that's useable for
> all capabilities so it can replace the oracle hack aswell. But the
> proponents of the patch weren't iterested to invest the tiniest bit
> of work over what they submited.
And as I mentioned a few times, the authors have neither the inclination
nor the ability to do that, because they are not kernel hackers. The
realtime LSM was written by users (not developers) of the kernel, to
solve a specific real world problem. No one ever claimed it was the
correct solution from the kernel POV.
I know Jack disagrees but I for one am glad to see the max-RT-prio
rlimit patch going in. This probably reflects my sysadmin background,
PAM does not scare me at all. Anyway it solves the same problem and
will be invisible to any user with a reasonable distro. If musicians
end up having to tweak the PAM configuration, then I would say the
distro has failed miserably.
Lee
>And as I mentioned a few times, the authors have neither the inclination
>nor the ability to do that, because they are not kernel hackers. The
>realtime LSM was written by users (not developers) of the kernel, to
>solve a specific real world problem. No one ever claimed it was the
>correct solution from the kernel POV.
i would just like to add that its very disappointing that the LSM,
having been included in the kernel (apparently very much against
Christoph's and others' advice) turns out to be so useless. from
outside lkml, LSM appeared to be a mechanism to allow
non-kernel-developers to create new security policies (perhaps even
mechanisms) without trying to tackle the entire kernel. instead, we
are now getting a fix which, while it solves the same problem, has
required substantive analysis of its effect on the overall kernel, and
will require continued vigilance to ensure that it doesn't now or
later cause unintended side effects. LSM appeared to be the "right"
way to do this in terms of modularity - it is disappointing to find it
has so little support (close to zero to judge from this debate) on
LKML despite being present in the kernel.
--p
On Mon, 2005-03-07 at 20:33 -0800, Matt Mackall wrote:
> On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> >
> > So I still have the rt-lsm patch floating about, saying "merge me, merge
> > me!". I'm not sure that the world would end were I to do so.
> >
> > Consider this a prod in the direction of those who were pushing
> > alternatives ;)
>
> I think Chris Wright's last rlimit patch is more sensible and ready to
> go. And I think I may have even convinced Ingo on this point before
> the conversation died last time around. So here's that patch again,
> updated to 2.6.11. Compiles cleanly. Chris, please add a signed-off-by.
>
> <snip>
>
> Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> priorities. Defaults to traditional behavior. Originally written by
> Chris Wright.
The nice part is really useful for me. With it i can allow users to
renice their previously niced jobs (eg. from 19 to 0). At the moment
they need to call me and i do this as root.
If this rlimit approach is not the solution for the audio RT stuff, can
the nice part merged anyway?
utz
Paul Davis <[email protected]> wrote:
>
> >And as I mentioned a few times, the authors have neither the inclination
> >nor the ability to do that, because they are not kernel hackers. The
> >realtime LSM was written by users (not developers) of the kernel, to
> >solve a specific real world problem. No one ever claimed it was the
> >correct solution from the kernel POV.
>
> i would just like to add that its very disappointing that the LSM,
> having been included in the kernel (apparently very much against
> Christoph's and others' advice) turns out to be so useless. from
> outside lkml, LSM appeared to be a mechanism to allow
> non-kernel-developers to create new security policies (perhaps even
> mechanisms) without trying to tackle the entire kernel. instead, we
> are now getting a fix which, while it solves the same problem, has
> required substantive analysis of its effect on the overall kernel, and
> will require continued vigilance to ensure that it doesn't now or
> later cause unintended side effects. LSM appeared to be the "right"
> way to do this in terms of modularity - it is disappointing to find it
> has so little support (close to zero to judge from this debate) on
> LKML despite being present in the kernel.
>
That, plus the fact that inherited capabilities could also be used here,
except they don't work right. That's a nice, simple and long-standing
kernel feature which I think we should have fixed up before piling in more
security features.
But I've said that often enough. If nobody has a sufficient need for
fixed-up-caps to actually put work into it, nothing happens. And it's a
lot of work, because this is a scary feature.
On Tue, Mar 08, 2005 at 01:55:55PM -0500, Lee Revell wrote:
> And as I mentioned a few times, the authors have neither the inclination
> nor the ability to do that, because they are not kernel hackers. The
> realtime LSM was written by users (not developers) of the kernel, to
> solve a specific real world problem. No one ever claimed it was the
> correct solution from the kernel POV.
And I told you that doesn't matter. If someone wants a feature in they
should find a way to make it palable. We're not accepting such excuses
to put in crap.
On Tue, 2005-03-08 at 21:20 +0000, Christoph Hellwig wrote:
> On Tue, Mar 08, 2005 at 01:55:55PM -0500, Lee Revell wrote:
> > And as I mentioned a few times, the authors have neither the inclination
> > nor the ability to do that, because they are not kernel hackers. The
> > realtime LSM was written by users (not developers) of the kernel, to
> > solve a specific real world problem. No one ever claimed it was the
> > correct solution from the kernel POV.
>
> And I told you that doesn't matter. If someone wants a feature in they
> should find a way to make it palable. We're not accepting such excuses
> to put in crap.
>
Fine. Consider it a proof of concept. I'm satisfied if any solution
gets merged, it doesn't have to be this one.
I am still confused about why the LSM framework was merged in the first
place.
Lee
On Tue, 8 Mar 2005, Lee Revell wrote:
> I am still confused about why the LSM framework was merged in the first
> place.
The purpose of LSM is to allow different security models to be
implemented. IMHO, a security model here meaning a complete or otherwise
significantly enhancing system-wide framework, such as SELinux.
I don't think LSM is a suitable framework for upstream merging of trivial
or experimental access control enhancements. They should either be made
part of the core kernel under LSM control or incorporated directly into an
existing LSM.
One of the reasons I would put forward for this is that it can be
dangerous to allow the user to arbitrarily compose security modules.
Also, from an architectural point of view, it's better to think about
security models at a high level with broadly defined components (e.g.
"DAC" and "MAC"), not as a collection of miscellaneous features.
In the case of this code, I would suggest integrating it into the core
kernel, and providing an LSM hook to allow other LSMs to mediate it.
As an example, see the vm_enough_memory hook.
- James
--
James Morris
<[email protected]>
>> Andrew Morton <[email protected]> writes:
>> > Does anyone have serious objections to this approach?
> On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote:
>> 1. is likely to introduce multiuser system security holes like the one
>> created recently when the mlock() rlimits bug was fixed (DoS attacks)
Matt Mackall <[email protected]> writes:
> I wouldn't say "likely". But anything's possible, so I wouldn't rule
> it out entirely.
I wasn't predicting a bug in your code, just pointing to a known PAM
problem. The lack of good documentation and overly obscure PAM
interfaces cause some (most?) distributions to ship with broken PAM
configurations. Debian includes pam_limits.so in seven different
/etc/pam.d files, yet their /etc/security/limits.conf is empty.
When the recent mlock() rlimits bug fix was merged, it had the
unintended effect of suddenly granting almost every user unlimited
mlock() privileges. I suspect something similar will happen for this
new rlimit. Mounting a DoS attack becomes child's play for anyone.
This is OK for me, but a disaster for shared system admins. That is
why these kinds of API changes should be avoided in a stable release.
The big advantage of the LSM approach is that we can be confident it
will have no effect on systems that do not load it. Further, the
sysadmin can easily check that it's not present. None of that is true
for this rlimits API change.
>> 2. requires updates to all the shells
>
> Requires update to the PAM distro for our purposes.
That, too.
>> 3. forces Windows and Mac musicians to learn and understand PAM
>
> Or for the distro (ubuntu or whatever) to catch up. The alternative is
> for the user to compile their own kernel module and mess with its
> arcane interface.
No, this LSM is already included in several distributions.
>> 4. is undocumented and has never been tested in any real music studios
>
> Well you'll have a bit to test it before it goes to Linus.
Only toy tests will be possible without the required userspace tools.
--
joq
On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote:
> >> 4. is undocumented and has never been tested in any real music studios
> >
> > Well you'll have a bit to test it before it goes to Linus.
>
> Only toy tests will be possible without the required userspace tools.
Chris posted the requisite change to pam_limits as well.
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall <[email protected]> writes:
> On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote:
>> >> 4. is undocumented and has never been tested in any real music studios
>> >
>> > Well you'll have a bit to test it before it goes to Linus.
>>
>> Only toy tests will be possible without the required userspace tools.
>
> Chris posted the requisite change to pam_limits as well.
Sure.
You and Chris and I can find a way to test it. Those are "toy tests".
The RT-LSM has been used for over a year by hundreds (probably
thousands) of musicians in studios making real music. That's what I
mean by "real music studios". We won't be able to do that kind of
testing for the rlimits solution until next year.
--
joq
On Mon 07-03-05 23:30:57, Jack O'Quin wrote:
> Andrew Morton <[email protected]> writes:
>
> > Matt Mackall <[email protected]> wrote:
> >>
> >> I think Chris Wright's last rlimit patch is more sensible and ready to
> >> go.
> >
> > I must say that I like rlimits - very straightforward, although somewhat
> > awkward to use from userspace due to shortsighted shell design.
> >
> > Does anyone have serious objections to this approach?
>
> 1. is likely to introduce multiuser system security holes like the one
> created recently when the mlock() rlimits bug was fixed (DoS attacks)
Default is unchanged and you claim your boxes are single-user-a-time,
anyway.
> 2. requires updates to all the shells
No. Just set it during login.
> 3. forces Windows and Mac musicians to learn and understand PAM
While you force them to mess with security modules. I'd say thats and improvement.
And "understanding PAM" in this case means updating two files, adding one
line to each.
> 4. is undocumented and has never been tested in any real music studios
So write the docs and test it.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms