cargo pgrx test --runas
#1652
cargo pgrx test --runas
#1652
Conversation
```shell $ cargo pgrx test pg14 --runas testuser --pgdata=/tmp/pgrxtest ``` This adds two new arguments to `cargo pgrx test`: `--runas <username>` and `--pgdata </writable/path>` Together, these will initidb, createdb, dropdb, and run postgres as the "runas" user. Extension artifacts are copied with `cargo pgrx install --sudo`, which will also require the current user be able to become root. In general, these options are designed for the unusual situation where one needs to be "root" in order to run extension tests, but, of course, Postgres is not allowed to be root.
| name: cargo pgrx test --runas | ||
|
|
||
| on: | ||
| push: | ||
| branches: [ develop ] | ||
| pull_request: | ||
| branches: [ develop ] | ||
|
|
||
| env: | ||
| CARGO_TERM_COLOR: always | ||
| RUST_BACKTRACE: 1 | ||
|
|
||
| jobs: | ||
| ubuntu: | ||
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v2 | ||
| - uses: Swatinem/rust-cache@v2 | ||
| with: | ||
| prefix-key: "v1-cargo-pgrx-test--runas" | ||
|
|
||
| - name: Install Postgres deps | ||
| run: | | ||
| sudo apt-get update -y -qq --fix-missing | ||
| sudo apt-get install -y postgresql-server-dev-14 | ||
|
|
||
| - name: Report version | ||
| run: cargo --version | ||
|
|
||
| - name: Install cargo pgrx | ||
| run: cd cargo-pgrx && cargo install --path . --debug | ||
|
|
||
| - name: cargo pgrx init | ||
| run: cargo pgrx init --pg14=$(which pg_config) | ||
|
|
||
| - name: Test cargo pgrx test --runas | ||
| run: cd pgrx-examples/arrays && cargo pgrx test pg14 --runas postgres --pgdata=/tmp/pgdata |
There was a problem hiding this comment.
Should we have a clone of this that uses just the env vars?
| if let Some(runas) = runas { | ||
| command.env("CARGO_PGRX_TEST_RUNAS", runas); | ||
| } | ||
|
|
||
| if let Some(pgdata) = pgdata { | ||
| command.env("CARGO_PGRX_TEST_PGDATA", pgdata); | ||
| } |
There was a problem hiding this comment.
What should win if they do
CARGO_PGRX_TEST_PGDATA="/some/path/somewhere" cargo pgrx test --pgdata="/another/path/elsewhere"?
note that as far as I am concerned "cargo pgrx should explode in their face and tell them not to do that" is a fine answer, but if we want, we can take the value from the environment by adding , env = "VARIABLE" to the list of "arguments" to the #[clap] attribute for that CLI arg.
There was a problem hiding this comment.
Note that cargo pgrx test doesn't actually use the environment variables. It sets them as part of the cargo test ... Command it runs. As such, it's pgrx-tests/src/framework.rs that reads them.
So... I think cargo pgrx test should just continue to ignore it, like it does every other envar it doesn't use.
There was a problem hiding this comment.
That's fair.
Hm. Maybe the test vars introduced here should be named PGRX_TEST_*? Not a serious concern, just wondering.
… a `sudo -u $runas mkdir -p ...`
pgrx-tests/src/framework.rs
Outdated
| let mut sudo_command = Command::new("sudo") | ||
| .arg("-u") | ||
| .arg(&runas) | ||
| .arg("tee") |
There was a problem hiding this comment.
You mentioned making a SudoCommand type and I think what I'd like to actually see is these ~4 lines made into a function/whatever that returns Command.
|
I should note that I am "good with this" in the sense that I have made my peace with the horrors of the world that is Unix access control. I do encourage you to bother the actions/checkout people, @theory, and try to fix things on their end. If this code turns out to have a security flaw of any significant import... anything that's not "you can pwn a computer that's already been pwned", which sometimes gets reported as a "vuln" anyways, then I will not hesitate to rip it out. Likely |
|
Fair enough, I've gone and complained in actions/checkout#956. |
|
There's also this bit of documentation, though:
This is for action containers, but I think it applies to workflows steps that run with |
|
Since Docker does support setting a user, I believe the problem is that GHA doesn't support it, so deescalating privileges seems like something GHA could support nonetheless. |
$ cargo pgrx test pg14 --runas testuser --pgdata=/tmp/pgrxtestThis adds two new arguments to
cargo pgrx test:--runas <username>and--pgdata </writable/path>Together, these will initdb, createdb, dropdb, and run postgres as the "runas" user.
Extension artifacts are copied with
cargo pgrx install --sudo, which will also require the current user be able to become root.In general, these options are designed for the unusual situation where one needs to be "root" in order to run extension tests, but, of course, Postgres is not allowed to be root.