too low-level Alex Shinn (25 May 2020 00:47 UTC)
Re: too low-level Amirouche Boubekki (28 May 2020 07:05 UTC)
Re: too low-level Alex Shinn (28 May 2020 08:27 UTC)
Re: too low-level Alex Shinn (28 May 2020 09:10 UTC)
Re: too low-level Amirouche Boubekki (03 Jun 2020 06:01 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 08:17 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 08:53 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 10:12 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 10:28 UTC)
Re: too low-level John Cowan (04 Jun 2020 15:59 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 16:29 UTC)
Re: too low-level John Cowan (04 Jun 2020 19:54 UTC)
Re: too low-level Marc Nieper-Wißkirchen (04 Jun 2020 20:55 UTC)
Re: too low-level Alex Shinn (04 Jun 2020 22:50 UTC)
Re: too low-level Arthur A. Gleckler (04 Jun 2020 23:32 UTC)
Re: too low-level John Cowan (05 Jun 2020 00:17 UTC)
Re: too low-level Alex Shinn (05 Jun 2020 04:07 UTC)
Re: too low-level John Cowan (05 Jun 2020 17:46 UTC)

Re: too low-level Marc Nieper-Wißkirchen 04 Jun 2020 16:28 UTC

It would be great if you could find some more universal solution to
this problem that also encompasses Scheme's read procedure. Two Scheme
processes may want to use Scheme datums instead of JSON to communicate
with each other.

And if one of the two Scheme processes is malicious, the other one
will want that the `read' procedure stops reading before the process
is killed.

Marc

Am Do., 4. Juni 2020 um 18:00 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Thu, Jun 4, 2020 at 4:17 AM Alex Shinn <xxxxxx@gmail.com> wrote:
>
>> The problem, however, is that this parameter is effectively read-only,
>> in the sense that the true limit is implementation and platform defined.
>> If the implementation has a stack depth limit of 100 recursions, trying
>> to set the parameter to 120 is of no use.  On the other hand, trying to
>> set the parameter to 80 is not needed.
>
>
> It may indeed be needed for the system as a whole.  If you are running a multi-threaded or multiprocessing server, for example, you have to give each thread/process a memory budget.  No one of them can be allowed to fill up all memory, or there is a denial of service.    Consider the case of Bad Guy sending an effectively infinite stream of left braces to one of the threads: eventually that thread will gobble up all of memory and the thread will crash, taking down all the threads processing innocent requests.  In the case of processes, you cannot rely on the OOM killer or equivalent to actually kill the process with the problem.
>
> Of course there can be no guarantee that if you set the limit to a given number, that that number of recursions or iterations is permitted: the true limiti is the minimum of the specified limit and the implementation limit.  But that's unavoidable.  Similarly, you can only determine by experiment just how much memory is allocated to represent particular JSON values.
>
>> It's theoretically possible for
>> an impl to _not_ use recursion and use a heap-based data structure,
>> but in this case the limit is only heap memory.  If you want to limit
>> heap memory, the depth doesn't help.  You need some limit on total
>> object size, otherwise they can just send a 10G string.
>
>
> As I keep pointing out (but evidently to no effect), a length limit for strings, arrays, and objects is also required; a depth limit alone is not enough.
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
> Some people open all the Windows; wise wives welcome the spring by moving
> the Unix.  --Advertisement for Unix Book Units (U.K.)
> (see https://9p.io/who/dmr/unix3image.gif)