Hacker News Reader

Comment by pjmlp | Hacker News Reader

Again nothing new on the horizon, DB2, Oracle and MS SQL Server have had JVM and CLR available for UDF for the last 20 years.

Naturally one needs to sell WebAssembly as being the first of a kind.

View on HN

The very first sentence from the blog post:

"User-defined functions (UDFs) have been a fixture in database systems for a considerable period of time, allowing users to extend the database’s built-in functionality to complement good ol’ SQL."

Granted, I'm biased, but I think we did a decent job elaborating from there on the novelties WebAssembly brings to this age-old field.

The very next sentence:

> developers are in most cases forced to use unfamiliar programming languages, typically unique to the database itself.

What parent correctly points out is that this simply isn’t true. Your examples of novelty are all things that were possible decades ago in most mainstream DBMSes. The SQLite one in particular is bizarre: it’s inherently an embedded db with bindings in every language.

Supporting user defined functions as compiled objects loaded into the database is as old as the hills. The sandboxing part is silly since no one in their right mind is going to expose their database to untrusted users in the first place.

> no one in their right mind is going to expose their database to untrusted users in the first place

I've seen projects do exactly this, with PostgreSQL row-level security.

https://www.graphile.org/postgraphile/

EDIT: Though to be clear, it does seem a terrible idea to me too....even when you prevent unauthorized access, there is always the issue of resource usage.

Apologies, I should have said something more like “exposing the database to untrusted users is a specific and narrow use case that needs way more db-specific planning”. RLS is really cool tech but you need to design your schema and application around it for it to be useful. Slapping some WASM on any existing databases (especially the vast majority which have nothing like the unique capabilities provided by RLS) isn’t going to buy anything that doesn’t exist already.

Also Hasura and PostgREST (thus by extension Supabase). I would also add that one of the entry barriers of such projects is the need to write UDF. Most developers are not used to write UDFs, and the languagea (plsql and likes) themselves lack the features and ease of modern languages and vary among database vendors.

As mentioned by other people there have been attempts to allow writing UDF using the JVM, Javascript, Python and so on, by they never caught on (and some of them are difficult to install) and are not that portable to other database vendors, they require installing third party extensions and so on.

I for one see WASM to be a good candidate for a really portable solution.

I think the fact that the most viable way to run Rust on the JVM right now is by compiling to WASM really says it all. JVM is going to die, WASM is the future.

Sure, as if Rust is taking Web development by storm.

Leave it for kernels and drivers.

Plus GraalVM runs LLVM bitcode if you have such a desire.

>The sandboxing part is silly since no one in their right mind is going to expose their database to untrusted users in the first place.

That's circular logic. You would not do it when it's unsafe. But when it is, it could open up entirely new use cases. Most obviously, infrastructure-as-a-service offerings.

It’s only circular when your conception of “safety” has a single dimension. The sort of execution sandboxing provided by WASM runtimes isn’t even close to the primary challenge with allowing untrusted users to run code inside a database.

In the general case using WASM as an object format does nothing to actually enable this use case beyond what exists.

It doesn’t really matter since this “untrusted user functions in the db” scenario is incredibly niche. The vast majority of database usage involves data access patterns entirely controlled by the developers of the system. Stored procedures in a variety of languages have long been available to such developers _and are generally considered an anti-pattern_.

What WebAssembly brings to the table is the ability for unprivileged users to upload their own arbitrary UDF to the DB for execution.

Database 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.

Spectre 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.

I 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.

You can still have Spectre attacks, check out this blot post

https://blog.cloudflare.com/mitigating-spectre-and-other-sec...

They 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.

The 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.

JavaScript and Python have been used for this since literally the 90s.

How will that work with RLS and similar controls?

I 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.

You’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.

Not 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-...

OK, that makes sense, though possibly less useful. I was thinking the UDFs would operate on the query or raw data.

Reply on news.ycombinator.com