"postgrestd" might be a slighty unfortunate name since there already exists postgrest, a daemon for providing a http interface to postgresql.
PL/Rust 1.0: now a trusted language for Postgres
51–57 of 57 posts
Re: PL/Rust 1.0: now a trusted language for Postgres
#52This looks risky to me. Rust is not a sandbox language. It's designed to catch accidental mistakes, not intentionally malicious code.
They've taken extra precautions to plug known holes, but it is using Rust beyond what it was designed for.
Re: PL/Rust 1.0: now a trusted language for Postgres
#53Earlier quoted context omitted.
The trust is not just banning unsafe, it is using a limited std: > The "trusted" version of PL/Rust uses a unique fork of Rust's std entitled postgrestd when compiling LANGUAGE plrust user functions. https://github.com/tcdi/postgrestd
That doesn't matter. If you can use `unsafe` you can make syscalls directly.
A large number of unsoundness bugs only work if you have access to the stdlib, because they're flaws in stdlib types and functions that use `unsafe` internally, and are supposed to present a safe interface around it.
If you a) don't have access to unsafe, and b) don't have access to the stdlib that lets you do powerful things without unsafe, then you're very limited in what you can do.
https://smallcultfollowing.com/babysteps/blog/2016/10/02/obs... discusses this further. Conceptually, you can think of "entirely Safe Rust" to be a very limited language, which you then progressively add "capabilites" to by exposing safe interfaces implemented with unsafe code. For example, Vec and Box (which require unsafe) grant safe code the ability to do heap allocations.
It's true that this is not designed as a security boundary. As I note in my comment above, the PL/Rust devs also make that clear. That doesn't mean it has no value as part of a defence in depth strategy.
Re: PL/Rust 1.0: now a trusted language for Postgres
#54"postgrestd" might be a slighty unfortunate name since there already exists postgrest, a daemon for providing a http interface to postgresql.
It's just the name of the repo: the actual target is ${arch}-postgres-linux-gnu.
Re: PL/Rust 1.0: now a trusted language for Postgres
#55Earlier quoted context omitted.
Normally yes, but it looks like the trusted PL/Rust being discussed here is limited to some subset of Rust. They specifically note that `unsafe` code is not allowed, which means you can't (for example) implement your own syscalls or construct a pointer into postgres internals memory. However, they make it clear that this is not intended to be your only defence against an attacker: > Note that this is done on a best-e…
I don't think it's really any defence at all against an attacker. I don't think Rust's `unsafe` was ever intended to be a security boundary. Surely all a "sufficiently motivated" attacker would need to do is peruse the unsound bugs on GitHub? https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... Those aren't considered to be security issues. Makes me wonder what the point of banning `unsafe` is at all. You'…
The rustc driver for trusted PL/Rust prevents using the subset of the Rust language required to trigger those issues. Most of them are things that would have a hard time traversing the Postgres procedure call boundary, anyways, in a legitimate use-case, so this isn't expected to meaningfully affect actual user code.
Re: PL/Rust 1.0: now a trusted language for Postgres
#56this is an exciting development for Postgres. Since PL/Rust is now a trusted language, it means that cloud providers like RDS and Supabase will be able to provide it. This means that you can write your database functions in rust, as an alternative to pgplsql / plv8. (disclosure: i work at supabase)
But bear in mind, those providers generally don't provide all trusted languages out there already. PL/Java has existed for a long time, has a trusted mode, and isn't supported by Supabase for example.
Re: PL/Rust 1.0: now a trusted language for Postgres
#57Earlier quoted context omitted.
You're right! My mistake. I was thinking of statement triggers. https://www.postgresql.org/docs/current/sql-createtrigger.ht... > The REFERENCING option enables collection of transition relations I don't see any examples of statement triggers...
https://stackoverflow.com/a/72397774 Note the use of new_table and old_table as aliases. Instead of single records in NEW and OLD, you can select against new and old sets of records.
I understand, and I've used the old and new table aliases. But I meant that I don't see a way to use those in the PL/Rust docs.