Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add runAsUser functionality #81

Closed
wants to merge 1 commit into from
Closed

Conversation

same-id
Copy link

@same-id same-id commented Jul 25, 2022

By supplying runAsUser it is possible to run initdb as non-root user
(which otherwise fails) even if the calling process runs as root.

In addition, flush logger on failures to get more detailed errors.

@same-id same-id force-pushed the master branch 3 times, most recently from e4af825 to a392b40 Compare July 26, 2022 10:29
By supplying runAsUser it is possible to run initdb as non-root user
(which otherwise fails) even if the calling process runs as root.

In addition, flush logger on failures to get more detailed errors.
@same-id
Copy link
Author

same-id commented Jul 26, 2022

Coverage is being a bit hard to achieve, even with added tests

@fergusstrange
Copy link
Owner

Hey @same-id, the Postgres instance should run as the same user that is running the GoLang process / tests making this feature a little redundant.

This is really a testing library so if it's being used in any other capacity that's not really within our core aim.

Happy to address the flush logger calls in a separate / altered PR however as that seems a good idea.

@same-id
Copy link
Author

same-id commented Aug 10, 2022

Hey!

I don't agree with the statement that it must run as the same user.

When we run our tests locally we are indeed enjoying the fact the test runs as the same user on our OSX/Linux.

But, on a more practical note, in our CI, when using the popular golang containers, the only available user is root.

So the tests just fail to run on these containers due to postgres limit to run as root (by the way - the failure message is not available to why this library fails - this is why this PR also adds relevant logger flushes also in failures).

Changing the user for the entire golang process is also not great in the popular golang container (lots of errors due to chmod problems of existing /go files that are accessible by root only)

Adding a nonroot user and running postgres as that user in the CI works super great - this way we can still run go as root but the postgres process will run as nonroot.

@fergusstrange
Copy link
Owner

Hey @same-id,

Here's an example in our very own build system where we spin up an Alpine Linux image (that defaults to root) and change user before running the test suite.

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 is really effective and requires pretty minimal code overhead.

I'd still be open to the logger flush code if you wish to open that in a separate PR.

@same-id
Copy link
Author

same-id commented Aug 21, 2022

Things are not always this easy thought :-)

We are building using earthly.dev and we pass GitHub credentials using an ssh agent integrating into the docker.

i.e. RUN --ssh go mod download

And since today the ssh sock is only accessible by the root user:

earthly/earthly#1549

(notice that this is fixed in buildkit/moby since they allow mode moby/buildkit#760)

All of the downloaded go modules are owned by root, so we need to do things like

USER root
RUN --ssh go mod download
RUN chmod ...
USER nonroot
RUN go test ... (postgres)

Notice that a simple RUN --ssh go test will not return successfully because modules might need to be downloaded so must be root for --ssh access but then postgres initdb will fail.

Obviously that's not an embedded-postgres problem, but IMO having a embedded-postgres run as root and fork as nonroot process just makes it a lot more flexible for developers.

At the moment we are using a fork of embedded-postgres which allows us to just specify a different nonroot user for the postgres process.

Will submit the failure logs as a different PR though.

@niclausse
Copy link

Support for root user to init db would be very helpful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants