Fork bomb question about Cygwin

[Corinna Vinschen]

On Jan 22 15:43, Corinna Vinschen via Cygwin wrote:
> Unfortunately there's a tricky difference between POSIX soft limits and
> the way Windows job limits work.
> 
> - Soft rlimits can be changed by any process, up or down, as long as the
>   new limit doesn't exceed the hard limit.  A child process inherits the
>   limits, but it can change (raise!) them right away, only limited by
>   the hard limit.
> 
> - Job limits on Windows can be changed by the process, but the limits
>   are accumulated if jobs are nested.  The lowest limit wins.
> 
>   If a child process inherited a job limit, it can't raise the limit,
>   unless it knows the name of the job object *and* has the right to set
>   limits on this object.  The problem here is, the current job the
>   process is running in, does not necessarily contain the information
>   about the real limit.  This information may be in a job object higher
>   up in the job hirarchy.  Unfortunately QueryInformationJobObject only
>   returns limits defined in this very job, not limits defined higher up.
>   And there's no way to fetch info about parent job objects, unless you
>   know their names or still have open handles on them.
> 
> All in all, that means, the current implementation of
> setrlimit(RLIMIT_AS) is not quite correct.  The job object is inherited
> by children, but then, if the child defines a new limit, it just creates
> a nested job with this limit inside the already existing job.  So the new
> limit is ignored if the parent (or grandparent, or ...) job defines a
> lower limit.
> 
> Unfortunately the child can't just breakaway from a job.  Only the parent
> can do this for a child at CreateProcess() time.  So we can't just
> breakaway at setrlimit time and create a new, independent job object.
> 
> The bottom line is, if we want to do this right, we have to redesign
> the entire setrlimit thingy:
> 
> - always allow BREAKAWAY_FROM_JOB
> - always start the child with BREAKAWAY_FROM_JOB
> - always create a new job object in the child after fork/exec implementing
>   the soft limits inherited from the parent
> - in setrlimit: always just change the current job object

But then again, if we do it like this, per-process limits work as
desired, but limits like RLIMIT_NPROC would not work.

Did I say something about a tricky difference...?


Corinna