PL/Rust 1.0: now a trusted language for Postgres
tcdi.github.io
PL/Rust 1.0: now a trusted language for Postgres
1–10 of 57 posts
Re: PL/Rust 1.0: now a trusted language for Postgres
#2this 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)
Re: PL/Rust 1.0: now a trusted language for Postgres
#3this 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)
for those who want to know the difference between "trusted" and "untrusted":
https://tcdi.github.io/plrust/trusted-untrusted.html
_Normally, PL/Rust is installed as a "trusted" programming language named plrust. In this setup, certain Rust and pgx operations are disabled to preserve security. In general, the operations that are restricted are those that interact with the environment. This includes file handle operations, require, and use (for external modules). There is no way to access internals of the database server process or to gain OS-level access with the permissions of the server process, as a C function can do. Thus, any unprivileged database user can be permitted to use this language._
Languages like pl_python are "untrusted" and give too much access to the file system, which is why cloud providers never support them on their platforms
Re: PL/Rust 1.0: now a trusted language for Postgres
#4this 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)
for those who want to know the difference between "trusted" and "untrusted": https://tcdi.github.io/plrust/trusted-untrusted.html _Normally, PL/Rust is installed as a "trusted" programming language named plrust. In this setup, certain Rust and pgx operations are disabled to preserve security. In general, the operations that are restricted are those that interact with the environment. This includes file handle operati…
cannot rust functions do anything a c function can?
Re: PL/Rust 1.0: now a trusted language for Postgres
#5Earlier quoted context omitted.
for those who want to know the difference between "trusted" and "untrusted": https://tcdi.github.io/plrust/trusted-untrusted.html _Normally, PL/Rust is installed as a "trusted" programming language named plrust. In this setup, certain Rust and pgx operations are disabled to preserve security. In general, the operations that are restricted are those that interact with the environment. This includes file handle operati…
cannot rust functions do anything a c function can?
only when using `unsafe` which this forbids
Re: PL/Rust 1.0: now a trusted language for Postgres
#6Earlier quoted context omitted.
for those who want to know the difference between "trusted" and "untrusted": https://tcdi.github.io/plrust/trusted-untrusted.html _Normally, PL/Rust is installed as a "trusted" programming language named plrust. In this setup, certain Rust and pgx operations are disabled to preserve security. In general, the operations that are restricted are those that interact with the environment. This includes file handle operati…
cannot rust functions do anything a c function can?
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-effort basis, and does not provide a strong level of security — it's not a sandbox, and as such, it's likely that a skilled hostile attacker who is sufficiently motivated could find ways around it
Re: PL/Rust 1.0: now a trusted language for Postgres
#7Earlier quoted context omitted.
for those who want to know the difference between "trusted" and "untrusted": https://tcdi.github.io/plrust/trusted-untrusted.html _Normally, PL/Rust is installed as a "trusted" programming language named plrust. In this setup, certain Rust and pgx operations are disabled to preserve security. In general, the operations that are restricted are those that interact with the environment. This includes file handle operati…
cannot rust functions do anything a c function can?
[deleted]
Re: PL/Rust 1.0: now a trusted language for Postgres
#8This looks amazing! This appears to perfectly fit the huge gulf between pl/pgsql and C in the Postgres stack.
Pl/pgsql, while not exactly elegant, is well suited to bridging that gap between imperative and set-oriented business logic within the database.
On the other hand, pl/pgsql is far from optimal for defining custom types and implementing operators for those types. For that, we've needed C.
But now the possibility opens up to create efficient custom types, operators, and other functions that can run at machine speed without depending on what a vendor decides to bundle or the mostly unvetted quality of some 3rd party's C code extension.
Potentially huge!
Re: PL/Rust 1.0: now a trusted language for Postgres
#9Earlier quoted context omitted.
cannot rust functions do anything a c function can?
only when using `unsafe` which this forbids
I don't know much about rust, so it seemed odd to me that just forbidding unsafe would make for a reasonable sandbox. At least for the postgres concept of "trusted language", that's supposed to mean things like closing off access to the filesystem. Not just typical file io calls either, but more obscure stuff like sendfile().
I do see that rust access to sendfile() would be via a syscall, which is in the unsafe category...so perhaps that's not the best example.
But it does make me curious how comprehensive a sandbox PL/Rust is providing, beyond just forbidding unsafe.
Re: PL/Rust 1.0: now a trusted language for Postgres
#10Earlier quoted context omitted.
cannot rust functions do anything a c function can?
only when using `unsafe` which this forbids
And there is also an alternative implementation to Rust std that blocks, among others, filesystem access via std::fs https://github.com/tcdi/postgrestd