for eg.

Say I (root) want user "kung" to only run 2 processes, and I want user "foo" to run 5 processs. How do I do this on Slackware 10?

I know in some distros of linux you can do this by editing /etc/security/limits.conf but slackware doesn't seem to have this feature

Use the ulimit command to set both the hard and soft limit for those users in the system profile for the shell used by those users. For example (of course these process limits are unreasonably small, but consistent with your question):

The hard limit will prevent the user from increasing the limit set.

Thanks for your reply.

BTW what's a good ulimit number for "root"? I just read an article here about a forkbomb crashing many linux distros that didn't have ulimit set to a sufficient number.


EDIT:

I'm sort of a noob...what file should I save this to and where exactly should I put it? permissions?


Shell is bash.

For bash, you can place the code in /etc/profile. A good limit is high enough not to interfere with your normal activity (whatever that is). For my machines, I use a limit of 256 for all users, including root. Smaller machines can probably get by with a lower value, while large servers will need a correspondingly large process limit. One size does not fit all.

I see...Ok I modified the code snippet and put it in the last part of /etc/profile

# ulimit for user
if [ "`/usr/bin/id -un`" == "kung" ]
then
ulimit -u -H 2
fi

I'm running slack on a:

466Mhz Intel Celery Proc w/ 128MB of ram


--EDIT--

I guess it's trial and error...

I seem to be having trouble with this script. It won't run, when I login as the user. It won't even run when I execute it as the user.


Another weird thing:

I can't find the executable for ulimit anywhere. I did a find / -name ulimit, which ulimit, and a whereis ulimit. I can't find the file! But when I run ulimit by itself it executes just fine.

This is because 'ulimit' is a bash builtin not an executable. You can check this by running the command type ulimit. As far as the code goes, try the following one, its very similar but I dont rely on the presence of the 'id' binary to make it work as the $USER environment var does the same thing and is guarenteed to be there if you run bash.

As you can probably tell this allows you to set root's ulimits a bit higher from non-root users. Just toss that into /etc/profile then re-login for it to take effect or simply run source /etc/profile if you dont want to log out.

limiting the total number of processes won't help.
say, you limited the amount of processes for yourself to 256.

after you start the forkbomb, there's no way to stop it anymore,
because you cannot do a "killall " or " su " to root to stop it ( " no more resources " )

..or is there a way... ?

edit:.don't bother....just do a ctl-alt-f6 and login as root.

egag

Good point!

On a standalone desktop you really don't have to worry about it. Only usefull if you are running a server and you've given out accounts to other people. And if you don't trust the people enough then you shouldn't be giving them accounts on your box in the first place. If they do take advantage of the account you can just take the account away from them.

Just saying becuase in order for the fork bomb to be used on your box the person has to have an account on you box. In reality the could just chuck some app like firefox in a for loop and keep opening up new ones and get the same effect. Now in reallity if that did happen I assume their account on your box would be revoked indefinetely . In they can't do any permanent damage because they can't use it to gain any kind of elevated privalages so why worry about it.

To limit execution of a large app in a loop, you can use memory limits as well:

# No core files by default
ulimit -c 0 > /dev/null 2>&1
# 768MB virtual memory limit
ulimit -v 786432 > /dev/null 2>&1
# 384MB resident memory limit
ulimit -m 393216 > /dev/null 2>&1
# 256 max processes per user
ulimit -u 256 >/dev/null 2>&1

Killing the loops isn't a problem. Many will fail on their own once they hit the resource limit. Those that don't can be killed from another login session (the limits are per session). System performance won't be an issue, unless you've set the limit too high. If neither -H nor -S is specified, both the soft and hard limits are set. The documentation for ulimit is in the bash man page (man bash).

@chbin
yes, that's true, but i was thinking about smth. like a forkbomb could happen
when i just try a ( bad ) script i wrote myself.
i do not have much experience with script-writing and Murphy's law being valid, it could happen.

but now i know a way to stop it....

egag

@macemoneta
the script won't fail when it hits the limit, it just keeps on trying.
but limit memory could be an extra safety.

egag

since were on the topic of ulimits, is there a way to limit the cpu time of a particular process or particular user? I'm assuming there has to be, never tried it though.

It depends on the nature of the application. For example, this fork bomb will fail:

:(){ :|:&};:

That expands to:

So it's basically creating a subroutine that invokes two copies of itself recursively, then it invokes the subroutine.

When executed with a process limit, it will halt forking at the limit, and all the recursive invocations will end. True fork bombs tend not to try to do real work (since that would limit their effectiveness at filling the system with processes). The more real work (or processing delays) the less likely that the processes will self terminate. As process slot are opened the existing looping processes will fill them. You can find who's running the loop with:

/bin/ps -Afl | /bin/awk '{print $3}' | /bin/sort | /usr/bin/uniq -c | /bin/grep -v UID | /bin/sort -n

Then kill that user's processing with:

skill -u username