6 ms·
What WebAssembly brings to the table is the ability for unprivileged users to upload their own arbitrary UDF to the DB for execution.
by 10000truths 3y ago
What WebAssembly brings to the table is the ability for unprivileged users to upload their own arbitrary UDF to the DB for execution.
- paulryanrogers 3y agoThey can't be completely arbitrary without user trust. My guess is security directives like invoker vs creator will need to be specified and checked appropriately whenever the assemblies are installed.
- 10000truths 3y agoThe whole point of having a sandboxed runtime like WebAssembly is that the code can be executed without user trust, as the user cannot pierce the isolation boundary or exceed the resource limits provided by the sandbox.
- paulryanrogers 3y agoHow will that work with RLS and similar controls?
- 10000truths 3y agoI don't see why UDFs and RLS would need to interact, they're orthogonal concepts that can work in tandem. The DB engine filters out the rows that fail the RLS check, then apply the UDF to the remaining rows.
- paulryanrogers 3y agoOK, that makes sense, though possibly less useful. I was thinking the UDFs would operate on the query or raw data.
- semiquaver 3y agoYou’re exactly right that these are orthogonal. The data isolation is the much harder part (the type of sandboxing provided by WASM has long been available via interpreted languages, see pl/v8 et al). Without exception the existing APIs mentioned in this article don’t attempt to handle “data sandboxing” since it’s so application specific. So it remains the case that exposing your db to user defined functions is dangerous without a ton of work, and WASM in no way reduces the amount of work needed.
- colanderman 3y agoNot necessarily true. E.g. in PostgreSQL, the planner is free to evaluate predicates prior to imposing RLS constraints, so long as the functions in the predicate are marked LEAKPROOF [1]. (They aren't by default.) This is because UDFs can write to tables, and perform I/O in other ways depending on system configuration and security policy. Just because the UDFs are in WASM instead of one of the other UDF languages doesn't eliminate the need for a security system. (Aside -- curiously in PostgreSQL, the privilege system isn't even strong enough to prevent something as innocuous as e.g. reading a view owned by another user from dropping your own tables.) [1] https://www.postgresql.org/docs/15/sql-createpolicy.html#id-1.9.3.75.7 https://www.postgresql.org/docs/15/sql-createpolicy.html#id-...
- BulgarianIdiot 3y agoJavaScript and Python have been used for this since literally the 90s.
- marcosdumay 3y agoDatabase privileges have always been completely uncoupled from each other. If you want some user to just run his code, you can already say so, and that has been true for decades.
- _0w8t 3y agoSpectre and other hardware bugs are not going to be fixed for code running in the same address space. The moment DB allows untrusted WebAssembly to run, then that code can read anything the DB server keeps in memory.
- 10000truths 3y agoI don't see how Spectre or hardware address spaces are relevant here. WASM code cannot access memory that is not explicitly provided to the sandbox, by design. Each load/store opcode is bounds-checked by the WASM engine to ensure that. Wouldn't be much of a sandbox, otherwise.
- rockwotj 3y agoYou can still have Spectre attacks, check out this blot post https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/ https://blog.cloudflare.com/mitigating-spectre-and-other-sec...