Re: message queue limits

[Andrew Morton]

Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx> wrote:
>
> 
> Hi Andrew!
> 
> On Thu, Apr 15, 2004 at 03:54:08PM -0700, Andrew Morton wrote:
> > Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx> wrote:
> > >
> > > This adds a new "RLIMIT_SIGPENDING" limit, which is used to limit
> > > per-uid pending signals. Currently an unpriviledged user can queue 
> > > more than maximum of allowed signals and cause overall system 
> > > malfunction.
> > 
> > So now it takes two users to gang up and do the same thing.  
> 
> Decrease rlim_cur then. Usually people dont have several accounts 
> on the same box.

You underestimate the deviousness of university students.

> > We should either exempt root from the global check or simply remove the global > limit
> > altogether.
> 
> Then allow for unlimited pending signals? Are you sure?

I think so.  If

	(number of users * rlimit(RLIMIT_SIGPENDING) * sizeof(struct sigqueue))

is a significant proportion of available lowmem then someone screwed up.

Given that we're currently allowing 1024 sigqueues kernel-wide, it seems
reasonable to permit 128 per user, and infinity for root.  At 144 bytes
each, that's 17k of pinned memory per user.  No big deal.

In fact I'd be inclined to allow 1024 per user as a default, just to be
sure that existing installations will not break.  Think: a machine running
a single application which wants all 1024.

> > Is it possible for a process to do setuid() with outstanding signals?  If
> > so, they may end up with a negative current->user->signal_pending?
> 
> Nice catch, root can do that and I think current->user->signal_pending can get
> negative. Not completly sure though.

Me not sure either.  I've noticed that anything with "signal" in the
subject seems to cause kernel developers' "Reply" buttons to malfunction. 
Funny, that.

> > You need to initialise ->signal_pending in alloc_uid().
> 
> --- signal.c.orig	2004-04-15 20:44:17.458438104 -0300
> +++ signal.c	2004-04-15 20:45:36.850368696 -0300
> @@ -288,7 +288,8 @@
>  		return;
>  	kmem_cache_free(sigqueue_cachep, q);
>  	atomic_dec(&nr_queued_signals);
> -	atomic_dec(&current->user->signal_pending);
> +	if (atomic_read(&current->user->signal_pending) > 0)
> +		atomic_dec(&current->user->signal_pending);
>  }

hrm.  I guess that's OK.  It does mean that there's a window in which the
user won't be able to queue as many signals as he expected to, but he was
doing weird stuff anyway.

It needs a comment though.

> > What are you doing for testing of this?
> 
> Simple app posted by Nikita (attached) together with MySQL and 
> sql-bench for creating mysql threads.
> The setuid() was added by me now.

OK, but you haven't tested dropping the rlimit?

Hey, I just discovered something.  In both bash and zsh you can do

	ulimit 4 1024

and it sets RLIMIT_CORE for you.  How very sensible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/