From fd98ae8a17bf1181f89146e497a6fa74cee4dd8c Mon Sep 17 00:00:00 2001 From: Albert Chu Date: Thu, 1 Feb 2024 12:24:28 -0800 Subject: [PATCH] rfc43: add constraint comparison limits Problem: A caller has the ability to specify an unbounded sized constraint object, which could serve as a denial of service (DoS) attack on the job list service. Add description of comparison limits for constraints. By limiting total number of "checks", we can bound constraints and their ability to DoS the job list service. --- spec_43.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/spec_43.rst b/spec_43.rst index 9f07e5d..0a25be5 100644 --- a/spec_43.rst +++ b/spec_43.rst @@ -247,6 +247,20 @@ Filter jobs that belong to userid 42 and were submitted after January 1, 2000. { "and": [ { "userid": [ 42 ] }, { "t_submit": [ ">946713600.0" ] } ] } +In order to limit the potential for a constraint to cause a denial of service (DoS) or long job list service hang, the instance owner can configure a maximum number of *comparisons* a constraint can consume while filtering jobs. Every "check" against a job is considered a comparison. In the last example above, the constraint is looking for all jobs belonging to userid 42 and submitted after January 1, 2000. It will consume at most 2 *comparisons* for each job. The ``userid`` check will always consume 1 comparison and the submission time will consume a comparison if the ``userid`` check passes. + +After the maximum number of *comparisons* is consumed, an error is returned to the caller. The caller can decrease their search footprint by limiting their search using other inputs in the job list request or making tighter constraints. For example, take following two constraints: + +.. code:: json + + { "and": [ { "queue": [ "foobar" ] }, { "userid": [ 42 ] } ] } + +.. code:: json + + { "and": [ { "userid": [ 42 ] }, { "queue": [ "foobar" ] } ] } + +In these examples the caller wants to filter jobs submitted to the queue foobar and submitted by userid 42. The only difference is the order of the checks. If "foobar" is the most common queue in the system (i.e. the check for queue "foobar" typically succeeds) and ``userid`` is not the most common user in the system (i.e. the check for userid "42" typically fails), the latter constraint will consumes fewer comparisons. + List ====