All of lore.kernel.org
 help / color / mirror / Atom feed
From: Natanael Copa <mlists@tanael.org>
To: Triffid Hunter <triffid_hunter@funkmunch.net>
Cc: redoubtable <redoubtable@netcabo.pt>, linux-kernel@vger.kernel.org
Subject: Re: fork()
Date: Fri, 25 Mar 2005 08:28:29 +0100	[thread overview]
Message-ID: <1111735709.14150.12.camel@nc> (raw)
In-Reply-To: <42430439.6090102@funkmunch.net>

On Fri, 2005-03-25 at 04:17 +1000, Triffid Hunter wrote:
> you can limit the max number of processes by putting the following into /etc/security/limits.conf (on my distro, and quite a number of others according to google too)
> 
> *	hard	nproc	<max # processes>
> 
> you can also limit quite a number of other things in this file, and other files in that directory.

I bet your PAM nonaware daemons started at boot are not affected by
those settings. The point is that if you gain access through a non-root
daemon started from boot scripts, you are no longer limited
by /etc/security/limits.conf.

Try to set hard nproc limits for user UID and run this from your boot
script:

#define UID 65534
#define MAX 65535

int pids[MAX];
int main() {
        int count = 0; pid_t pid;
        if (setuid(UID) < 0) { perror("setuid"); exit(1); }
        while ((pid = fork()) >= 0 && count < MAX) {
                if (pid == 0) { sleep(300); exit(); }
                pids[count++] = pid;
        }
        printf("Forked %i new processes\n", count);
        while (count--) kill(pids[count], SIGTERM);
}

You will see that even if user UID is limited
in /etc/security/limits.conf it will be able to fork many more
processes.

> > It should exist a global limit in case someone could spawn 
> > a shell without limits through some flawed application.

I agree on this one. Or the RLIMIT_NPROC should be set to a lower value
by default.

--
Natanael Copa



      reply	other threads:[~2005-03-25  7:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-24 16:45 fork() redoubtable
2005-03-24 18:17 ` fork() Triffid Hunter
2005-03-25  7:28   ` Natanael Copa [this message]

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=1111735709.14150.12.camel@nc \
    --to=mlists@tanael.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=redoubtable@netcabo.pt \
    --cc=triffid_hunter@funkmunch.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.