Re: Fork bomb question about Cygwin

On Jan 21 20:37, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Hello All,
> 
> I apologize in advance if my question is off-topic for this mailing
> list, and if so, y'all are free to just ignore it.
> 
> In essence, I was under a (seemingly wrong) impression that user-level
> classic fork-bomb such as the infamous,
> 
> ":(){ :|:& };:"
> 
> would not be possible because Windows would run out of memory creating
> the processes, and at some point Cygwin's fork() would fail, thus,
> stopping the chain reaction.
> 
> That obviously is not the case, and the above (run by a non-privileged
> user) kills the OS quite successfully, rendering it totally
> non-responsive (even mouse stops moving at some point as well) with
> only a hardware reset being able to bring it back to life.
> 
> (To confirm, I experimented with that on the all current Windows 10
> Pro.)
> 
> So the first part of my question is, whether this is actually expected
> to happen?

Yes.  As on Linux and other systems, there's no default restriction(*)
for the number of processes of an unprivileged user.

Since Cygwin is just a user space DLL in a user space environment,
and given fork() is implemented in terms of Windows' CreateProcess()
call, I'm fairly certain the same will happen in CMD, if you run a
"spawn"-bomb.

> By default Cygwin creates the user environment with unlimited
> processes (and I suppose that any user can just run "bash"
> unrestricted, thus obtaining the unlimited process resource).  Which
> then brings up a question about security of the system, as a whole.
> And so the second part is, is there any way to securely control /
> restrict the behavior?

This is not something controlled by Cygwin, rather by the OS.  Cygwin
provides the POSIX calls getrlimit/setrlimit, but obviously those have
to be implemented in terms of OS functions or faked.

The only implemented limits are RLIMIT_AS, RLIMIT_CORE, RLIMIT_NOFILE
and RLIMIT_STACK, and only RLIMIT_AS is actually calling into the OS to
install a restriction.

I just checked the MSDN man pages and it's possible to install a per-job
process limit.  But that only affects processes inside the job.
Assuming the process limit is established by a shell, only the child
processes inside this shell would be affected, so it's basically
equivalent to a soft limit in the terms of setrlimit.  I don't know of
any way to establish a hard limit in Windows, unless there's something
like a group policy.

Also, the job limit in Windows affects the number of processes, not the
number of threads.  So you can just as well create a limited number of
processes with so many threads that the OS gets dizzy either way.  The
Linux RLIMIT_NPROC restricts the number of threads per user due to the
way threads are implemented.

Looking on Linux, it doesn't really restrict unpriviledged users by
default a lot.  My desktop system has a default hard limit of 95356
processes per user.


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple