Interesting...

[X11]

Code: Select all

#include <sys/types.h>
#include <unistd.h>

int main()
{
        while(1)
        {
                fork();
         }
}


I run this on my new p133 box i set up with rh 8.0/WindowMaker/ect and it stopped any process from running.

[Void Main]

So why would you run that? Just to see if you can? It shouldn't stop any process from running. What should have happened is that if you ran it under a normal userid it would have spawned enough children to where you hit your "ulimit" for number of processes (which on many default Linux setups may be unlimited). Normally you would set this limit in /etc/profile with something like:

ulimit -u 40

which would limit each user to 40 processes. Without this limit you will just keep forking children until you use up all the system resources. You can also limit memory, etc:

ulimit [-SHacdflmnpstuv [limit]]
Provides control over the resources available to the shell and
to processes started by it, on systems that allow such control.
The -H and -S options specify that the hard or soft limit is set
for the given resource. A hard limit cannot be increased once
it is set; a soft limit may be increased up to the value of the
hard limit. If neither -H nor -S is specified, both the soft
and hard limits are set. The value of limit can be a number in
the unit specified for the resource or one of the special values
hard, soft, or unlimited, which stand for the current hard
limit, the current soft limit, and no limit, respectively. If
limit is omitted, the current value of the soft limit of the
resource is printed, unless the -H option is given. When more
than one resource is specified, the limit name and unit are
printed before the value. Other options are interpreted as fol-
lows:

-a All current limits are reported
-c The maximum size of core files created
-d The maximum size of a process’s data segment
-f The maximum size of files created by the shell
-l The maximum size that may be locked into memory
-m The maximum resident set size
-n The maximum number of open file descriptors (most systems
do not allow this value to be set)
-p The pipe size in 512-byte blocks (this may not be set)
-s The maximum stack size
-t The maximum amount of cpu time in seconds
-u The maximum number of processes available to a single
user
-v The maximum amount of virtual memory available to the
shell

If limit is given, it is the new value of the specified resource
(the -a option is display only). If no option is given, then -f
is assumed. Values are in 1024-byte increments, except for -t,
which is in seconds, -p, which is in units of 512-byte blocks,
and -n and -u, which are unscaled values. The return status is
0 unless an invalid option or argument is supplied, or an error
occurs while setting a new limit.

If you have your ulimit set properly and a user runs your while-true-fork program then it will start 40 processes and the user will be stuck until root kills his processes (the user would not be able to do a "ps" or "kill" because he is already at his process limit). root would do a "pkill -u user".

[Calum]

and if somebody, say X11 for example, were to ssh into grex and run that it might do what? (grex runs SunOS5 btw)

[Void Main]

and if somebody, say X11 for example, were to ssh into grex and run that it might do what? (grex runs SunOS5 btw)

Well, if grex has ulimits set for users which most commercial UNIX systems do by default then it wouldn't do anything more than spawn the number of processes that he is limited to, then of course he would have to ask for an administrator to kill his processes off so he can actually do something useful (or not useful) again. And then be chastised by the administrator when said administrator looks at the souce to what X11 had running. :)

Just type "ulimit -a" on the command line to see if your user account is limited. On my Red Hat 9 box the default seems to be "4095":

Code: Select all

[void@main void]$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 4095
virtual memory        (kbytes, -v) unlimited


[Calum]

reason i ask is that X11 told me he did that while logged into grex and it disconnected him. then i logged into grex a minute or so later and it was still working fine. thing is as i recall, X11 was telling me it would bring it down (which is why i logged in to see if it was online)

[Void Main]

If you were able to connect a minute or so later then it didn't bring the system down. I've never seen a Solaris system reboot in less than 10 minutes. And of course you could have checked the "uptime" command. It probably just ate up all his processes to his limit and booted him. The program probably then died along with all of it's children once he was booted. If so, he could probably log right back in. Now if he had started it in the background then he probably would not be able to log back in until an administrator killed all of his processes. Since it's Solaris then you are probably running a ksh and would need to nohup the program:

$ nohup ./myforkingprogram >/dev/null 2>&1 &

[X11]

Na grex has heaps of stuff to stop people doing this, but I run it on a Red-Hat 8.0 box (default setup) and root took ages to do a ps aux to see whats going on, and then kill the process.

[Void Main]

Setting your ulimit process limit to a lower number than the default 4096 should solve that.

[X11]

Cool.

[X11]

and if somebody, say X11 for example, were to ssh into grex and run that it might do what? (grex runs SunOS5 btw)

I found out that Grex kicks you off.

[Calum]

i am battling it out on this very subject here:
http://www.microsuck.com/forums/showthread.php?p=93213

and losing!

what are people's thoughts here about this issue, and how to fix it ie: should this be dealt with in the kernel, how does *BSD deal with it, is it a security flaw in linux etc.

[Void Main]

It's not a security flaw. In fact it's not a flaw at all and I don't understand the argument. For the distros you guys are talking about for the most part they are used by home users and the restraints are relaxed in some areas. If you are setting up a server where you will have multiple users logging on who you don't know first hand then you really should have an administrator 101 training which ulimit is a part of. You can also adjust hard system limits on users, groups, or entire system in the /etc/security/limits.conf file. You don't usually just install a server application without customizing and configuring it to your environment do you? If you are running a server you tailor these settings and the OS settings to fit the role it will be playing. If you are running an Oracle server you will need a lot more than 100 processes as Oracle can spawn thousands of processes. On the other hand, if I were setting up a server to allow users like X11 to log on I might set the default system ulimit for processes to 1.

If you want to see an even easier set of commands that will lock a Linux system up tighter than a drum instantly under a normal user account without using fork or having to compile anything I could show you. That *is* a flaw. All you have to do is enter just a few common characters on a command line. It might be fixed by now though.

[ZiaTioN]

Ahh the good ole fork bomb. Haven't seen one used in years.