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
