5 ms·
While I largely share your broader concerns, > ensuring that queries that should read only read seems to be the purview of the DBMS, setting appropriate accou
by dllthomas 6y ago
While I largely share your broader concerns,
> ensuring that queries that should read only read
seems to be the purview of the DBMS, setting appropriate account permissions. The bit you quoted said "a database user account that has only read access".
- isbvhodnvemrwvn 6y agoThis assumes you only deal with non-sensitive data (e.g. user profiles). Never mind that, how do you prevent denial of service attacks? I can run any allowed query on that database. Including 50 times cross join of the table I can read, sorted by random.
- dllthomas 6y ago> This assumes you only deal with non-sensitive data (e.g. user profiles). Not really. You can do row or column level permissions. Details very much depend on your DBMS. > Never mind that, how do you prevent denial of service attacks? I have no real answer, and I never suggested that I would. Denial of service attacks (deliberate or accidental) are one piece of the "broader concerns" that I very much share. In theory, a sufficiently advanced DBMS might be able to assign users quotas, and if your users are stable that may be sufficient for some use cases, but I am skeptical.
- WesolyKubeczek 6y agoOn MySQL, you can run SLEEP() or BENCHMARK() as a read-only user to your heart's content. You cannot restrict access to these functions, and letting the wide internets play with them will bring your server to its knees by clogging up all connections and hogging up its CPUs.
- derision 6y agoSolution: Don't use MySQL
- eloff 6y agoAll rdbms have similar issues with built-in functions. Plus you can easily create pathological queries that do the same.
- WesolyKubeczek 6y agoPostgreSQL's SQL is Turing-complete. Imagine the possibilities!
- dllthomas 6y agoI wasn't contradicting the bits about DOS attacks, which remain very much a concern, even when no one is malicious.