Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PL/Rust 1.0: now a trusted language for Postgres

tcdi.github.io

Post reply on HN
Print view View original

11–20 of 57 posts

Re: PL/Rust 1.0: now a trusted language for Postgres

#11

Post by iudqnolq »

tyingq wrote: post #9
lexicality wrote: post #5

Earlier quoted context omitted.

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 categ…

pl/rust is its own target platform, so they provide their own standard library*. The IO stuff all panics, for example. (In Rust a panic should be used to indicate invariant failure. pl/rust catches panics and converts them to postgres errors).

In Rust you'd normally be able to link c code, but calling c requires unsafe because you have to manually ensure the c code upholds any relevant Rust invariants.

> But it does make me curious how comprehensive a sandbox PL/Rust is providing, beyond just forbidding unsafe.

They also hook the compiler and try and detect shenanigans. It's not perfect, but it's pretty thought out.

*Technically the Rust standard library builds on top of a lower-level io module, which is all you have to replace.

Re: PL/Rust 1.0: now a trusted language for Postgres

#12

Post by techdragon »

kiwicopple wrote: post #2

this 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)

Can… but how long until they actually do provide it?

I’m a big fan of PostgreSQL and it’s constantly an annoyance to find cool new capabilities provided by extensions I can never use since I’m not going to manage my own database in a critical environment for a lot of reasons… I’ve done it before, I know how hard it is to do well, and I don’t want this to be my job anymore… so when I find cool stuff like vector search or graph traversals but can never use them it’s just a constant disappointment.

Does this “trusted” state actually translate into greater adoption by cloud providers or is it just something the developers behind this effort hope will happen?

Re: PL/Rust 1.0: now a trusted language for Postgres

#13

Post by chrismorgan »

lexicality wrote: post #5
zabzonk wrote: post #4

Earlier quoted context omitted.

cannot rust functions do anything a c function can?

only when using `unsafe` which this forbids

This implementation blocks file system access and is thus not vulnerable, but note that in Rust in general you can actually violate safety on some platforms without any `unsafe` by modifying magic files like /proc/self/mem. This is a known issue but considered unfixable (because the technical solution of marking opening a file as unsafe would cause far more trouble than it could ever hope to solve).

Re: PL/Rust 1.0: now a trusted language for Postgres

#14

Post by IshKebab »

chrismorgan wrote: post #13
lexicality wrote: post #5

Earlier quoted context omitted.

only when using `unsafe` which this forbids

This implementation blocks file system access and is thus not vulnerable, but note that in Rust in general you can actually violate safety on some platforms without any `unsafe` by modifying magic files like /proc/self/mem. This is a known issue but considered unfixable (because the technical solution of marking opening a file as unsafe would cause far more trouble than it could ever hope to solve).

It's more of an interesting fact than an issue to be fixed.

Re: PL/Rust 1.0: now a trusted language for Postgres

#15

Post by gpm »

tyingq wrote: post #9
lexicality wrote: post #5

Earlier quoted context omitted.

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 categ…

More than just forbidding unsafe, but not enough to make this secure against competent adversaries by their own admission. They argue postgres itself isn't secure against competent adversaries so this doesn't matter too much.

https://tcdi.github.io/plrust/plrust.html#what-about-rust-co...

Rust keeps a list of soundness bugs via a tag on github - they're pretty common:

https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...

Re: PL/Rust 1.0: now a trusted language for Postgres

#16

Post by IshKebab »

ekimekim wrote: post #6
zabzonk wrote: post #4

Earlier quoted context omitted.

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-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're going to need some other system anyway...

Re: PL/Rust 1.0: now a trusted language for Postgres

#18

Post by mkl95 »

systems wrote: post #17

why would anyone want to use PL/Rust over PL/PQSL? what is the use case?

> PL/Rust is a loadable procedural language that enables writing PostgreSQL functions in the Rust programming language

Use to write PostgreSQL functions in Rust. Also

> The top advantages of PL/Rust include writing natively-compiled functions to achieve the absolute best performance, access to Rust's large development ecosystem, and Rust's compile-time safety guarantees.

Re: PL/Rust 1.0: now a trusted language for Postgres

#19

Post by systems »

mkl95 wrote: post #18
systems wrote: post #17

why would anyone want to use PL/Rust over PL/PQSL? what is the use case?

> PL/Rust is a loadable procedural language that enables writing PostgreSQL functions in the Rust programming language Use to write PostgreSQL functions in Rust. Also > The top advantages of PL/Rust include writing natively-compiled functions to achieve the absolute best performance, access to Rust's large development ecosystem, and Rust's compile-time safety guarantees.

As someone who have done a lot of database development, none of these sound advantageous

Using a text oriented language like Perl with a good regexp engine might

DB performance, comes from indexes , table partitioning and in-memory tables and to compile query execution plans, so you save some time the very first you run a procedure

Re: PL/Rust 1.0: now a trusted language for Postgres

#20

Post by ixfo »

systems wrote: post #19
mkl95 wrote: post #18

Earlier quoted context omitted.

> PL/Rust is a loadable procedural language that enables writing PostgreSQL functions in the Rust programming language Use to write PostgreSQL functions in Rust. Also > The top advantages of PL/Rust include writing natively-compiled functions to achieve the absolute best performance, access to Rust's large development ecosystem, and Rust's compile-time safety guarantees.

As someone who have done a lot of database development, none of these sound advantageous Using a text oriented language like Perl with a good regexp engine might DB performance, comes from indexes , table partitioning and in-memory tables and to compile query execution plans, so you save some time the very first you run a procedure

Doing in-database computation can be very advantageous for some applications, and writing those functions in Rust would be fantastic for some uses, not least for the library ecosystem. I did some work on video similarity search with in-DB search which would've certainly benefited.
Post reply on HN