3 ms·
If someone can write their own SQL, it would be trivial to DoS the system. My guess is that the sublanguage is meant to prevent that (but it's just a guess).
by jeff-davis 4y ago
If someone can write their own SQL, it would be trivial to DoS the system. My guess is that the sublanguage is meant to prevent that (but it's just a guess).
- vbezhenar 4y agoThis sublanguage will either be useless or will not prevent DoS. The proper way to prevent DoS is to implement some kind of resource constraints for database queries. AFAIK for postgres every connection launches a separate database process. So in theory you can craft some kind of ulimits or cgroup limits which would restrict a process to a limited amount of RAM, CPU or IOPS. So if a given process will eat more RAM, it'll be killed, if it wants to mine bitcoins, it'll be throttled and killed by timeout eventually.
- taffer 4y ago> This sublanguage will either be useless or will not prevent DoS. Thinking in absolutes is not very helpful. PostgREST's API is designed to prevent DoS and it is flexible enough for most of your queries and when it isn't you can write a custom function and PostgREST will expose it for you as '/rpc/<my_function>'.
- jmull 4y agoI think that's separate from the language though. I'm not saying it would process any SQL... it can be restricted to whatever function and SQL patterns that are deemed acceptable. Realistically, though, your language is going to be seriously inflexible or allow DoS... In fact I think you're typically more likely to hit seriously inflexible before excluding the possibility of DoS. So I think you're going to need something besides the query language to prevent DoS anyway.