Run as a different user (non-root)

[mafredri]

Hi,

First off, thanks for an awesome project! We're using embedded-postgres over at coder/coder as a tool to quickly get up-and-running and it's been great.

We'd love to be able to launch embedded-postgres as a different (non-root) user to further improve the experience for users running Docker on macOS.

I'll spare you the full details as to why we'd need this functionality (for the curious coder/coder#5263), but TL;DR, we'd like to avoid extra steps where users have to change Docker socket permissions which has side-effects outside the container. The easiest way to achieve this is to run as root. Being able to run embedded-postgres as a different user would allow us to keep control within the main process running in the container.

I saw that there was already a PR for this functionality, #81, but I thought it would be worthwhile to open an issue for it to show our support for the feature.

Ours is just one use-case though, and I understand if you still feel it's not a great fit for your project. Cheers.

[fergusstrange]

Hi thanks for this.

We've received a few requests for this and it's something that will be considered with much more interest. I'll leave this open for anyone else who'd like to discuss.

[kotyara85]

That's actually a deal breaker, can't run in github actions

[justinrixx]

I'm also running into this as a limitation. The default golang docker images at our company run as root, so in order to get this to pass we'd have to maintain our own set of docker images specific to our team rather than using the latest shared ones (not to mention push for changes to our shared internal build scripts to run the build in the aforementioned docker image rather than the shared ones based off of go version, etc). Adding this feature would solve that for us.

[fergusstrange]

Hey both, we actually run using the Alpine Golang image on Github Actions for this project itself.

Here's the code we use to get this to run...

    name: Alpine Linux Platform Tests
    runs-on: ubuntu-latest
    container:
      image: golang:1.18-alpine
    steps:
      - uses: actions/checkout@v1
      - name: Set Up
        run: |
          apk add --upgrade gcc g++ && \
          adduser testuser -D
      - name: All Tests
        run: su - testuser -c 'export PATH=$PATH:/usr/local/go/bin; cd /__w/embedded-postgres/embedded-postgres && go test -v ./... && cd platform-test && go test -v ./...'

This can be found here

embedded-postgres/.github/workflows/build.yml

Line 57 in 9c9e366

alpine_tests:

[gpassini]

We're in a similar situation at the company I work for. Unfortunately even changing the user that runs all tests wouldn't work for us, because some test setups currently require root privileges and, although this is something we want to solve, it's a much bigger lift.

We've successfully tested a forked version of this repo, patched with changes from #81.
All we needed to do was to create a testuser in our Dockerfile (Debian based):

RUN adduser testuser

Then configure the Postgres database with the RunAsUser("testuser") configuration option.

Would you reconsider that PR, or a similar solution?
I could give a hand if more changes should be made to that PR before it's "mergeable" (also thanks for the project!).

[sam-utila]

Fork available here:
https://github.com/utila-io/embedded-postgres

[talig]

FWIW, I'm seeing this issue as well. The solution you're using makes A LOT of assumptions on the setup, and leaves whoever is trying to use this library with a research project "of how do I apply this to in my infrastructure". The suggested solution seems like it will spare people from that, and that might have intrinsic value.

I've tried to follow the example, it's not quite so simple.

Adding a testuser is relatively straight forward. You need to adjust the command to the relevant distro in the image, I'm with ubuntu, so it's:
adduser --disable-password --gecos "" testuser
In order to have it really be non-interactive.

This line is actually calling your tests, which means the parallel for people who are using this library would be running the their whole test suite with this user (when really, the only thing that needs to run like this is initdb).
su - testuser -c 'export PATH=$PATH:/usr/local/go/bin; cd /__w/embedded-postgres/embedded-postgres && go test -v ./... && cd platform-test && go test -v ./...'

For people who use e.g. Bazel I'm not really sure whether this is at all possible, and it's certainly not simple.

Please reconsider the contribution, in its absence this really nice library is far less useful than it could be.

[benjiro29]

Been looking to use embedded-postgres as a alternative to sqlite for remote deployment where we do not control the environment (and our clients are not tech savvy but they can do some basic tasks). One of the main stumbling blocks has simply been the root issue.

We also ran into issues where switching to a non-root user in docker environments made things more complex and error prone. As a result we ended up using sqlite more often as its a much easier solution for the clients, despite its lackluster feature set for us.

Embedded Postgres is a interesting potential tool for testing and environments where you have full control over said environment. But this lacking feature reduces the usefulness to step beyond.

[MrUsefull]

We wanted to use embedded-postgres for testing as well, but being unable to set the user or run as root means embedded-postgres is useless for us.

[benjiro29]

We wanted to use embedded-postgres for testing as well, but being unable to set the user or run as root means embedded-postgres is useless for us.

We ended up going with the Go compiled version of Sqlite ( modernc.org/sqlite ) in combination with zombiezen.com/go/sqlite ( Do not use the default go sql driver, it messes with sqlite performance ).

This solution has been been as performant and easier to integrated, with no issues of root/access. Doing 20k/s queries is plenty for clients ;)

Its a shame but the whole restriction on the root for embedded-postgres was a major deal breaker for us.

[g-getsov]

Same thing here, we're using a company wide container that builds all of our Go apps. Having to fork and support a different container just for our team because we want to do functional testing with an embedded db instance is a deal breaker. Modifying the company wide container to comply with the root restrictions is a big ask. Please merge in the MR 🙏