plrust icon indicating copy to clipboard operation
plrust copied to clipboard

RFC: Allowlist for dependencies

Open Hoverbear opened this issue 2 years ago • 0 comments

In #25 we discussed a bit about creating sandboxing for the user-written PL/Rust code. Part of that security posture is related to dependencies.

Right now, a user could go

CREATE EXTENSION IF NOT EXISTS plrust;
CREATE OR REPLACE FUNCTION sum_array(a BIGINT[]) RETURNS BIGINT
    IMMUTABLE STRICT
    LANGUAGE PLRUST AS
$$
[dependencies]
    some_malicious_crate = "1"
[code]
    Some(a.into_iter().map(|v| v.unwrap_or_default()).sum())
$$;
SELECT sum_array(ARRAY[1,2,3]);

Resulting in the build.rs or proc macros inside some_malicious_crate running on the database host. This is clearly not desirable.

Unfortunately, denying dependencies with a build.rs or proc macros would eliminate many very useful crates.

Instead, we'd like to create a way to configure an allow list of crates.

Obvious options for this are GUCs and tables.

Unfortunately, GUCs cannot be arrays. We could however have the GUC take a path perhaps.

Instead, this kind of potentially large dataset is typically stored in tables. So perhaps we could have a GUC which defines a table name which PL/Rust draws this data.

plrust.allowed_crate_table = "plrust.allowed_crates"

Where the table is

CREATE TABLE plrust.allowed_crates (
    name text,
    version text,
    features text
);

Given this list, PL/Rust could also pre-download and even pre-build these dependencies for use by users.

Additional ideas

For the sake of deployment cases, it may be useful to be able to point PL/Rust at an existing CARGO_HOME (eg ~/.cargo/) or existing registry. This would permit, for example, cases where a user wanted to deploy PL/Rust in an environment without internet.

Hoverbear avatar Mar 23 '22 17:03 Hoverbear